Config file #36
Config file #36
Conversation
Add CLI argument parsing Rename grist-electron to grist-desktop
SleepyLeslie
force-pushed
the
sleepyleslie/config-file
branch
2 times, most recently
from
bc42f77 to
e202313
Compare
SleepyLeslie
force-pushed
the
sleepyleslie/config-file
branch
from
e202313 to
6659e45
Compare
| "electron": "30.0.6", | ||
| "electron-builder": "23.6.0", | ||
| "@electron/notarize": "2.3.2" | ||
| "eslint": "9.x", |
There was a problem hiding this comment.
How do I use eslint on this repo? npx eslint at top level didn't do anything. npx eslint within the ext directory did stuff, giving a lot of errors. Just checking what expectation is being set here?
There was a problem hiding this comment.
The errors are expected (for now). There is too much legacy code that does not conform to eslint's default rules. Linting was introduced in this PR to help me check for (and auto fix) unsorted imports and missing semicolons. More linting-related changes will be added gradually.
| path.join(APPDATA_DIR, "home.sqlite3") | ||
| ); | ||
|
|
||
| const homeDBLocation = path.parse((process.env.TYPEORM_DATABASE as string)).dir; |
There was a problem hiding this comment.
Where did we land on trying to preserve/copy the existing home db? From my perspective as a know-nothing user, I just upgraded my version of Grist and "lost all my files".
I see that even if I find and copy across my old home db, I have still "lost all my files" because I'm a new and different user.
If I learn about the config file and set login.email to you@example.com I have still "lost all my files" because my login as the new and different user is remembered.
If I log out and log back in again, I can finally see my files.
A little bit worried about a wave of support requests as people upgrade, none of the above steps would be very obvious.
We could grit our teeth and just go through with it, is that your thinking? I know you have a modal planned.
There was a problem hiding this comment.
This is planned for the next PR which will implement the modal. I am thinking about a migration mechanism that detects version upgrades, performs migrations, and lets users know about the breaking changes as well as the automatic migration outcome.
Not sure if I should squeeze everything in here. I want to stop this PR from getting even larger.
There was a problem hiding this comment.
Just a thought (sorry I only now noticed this diff): we use elsewhere in Grist an awesome little tool ts-interface-checker + ts-interface-builder (created here!) which allow one to define a typescript interface, e.g.
{
server: {
port: number;
};
sandbox: {
flavor?: 'pyodide' | 'gvisor' | 'unsandboxed';
...
};
}
(with comments and everything), and then turn it into a "-ti.ts" file that works as a runtime descriptor. Then you could take a yaml file, and run it through ts-interface-checker that would use this descriptor, to check that the object satisfies this interface (and report reasonably informative errors).
Just sharing since it seems a nice way to do configs (vs INI files).
|
The config change has been deferred after some discussion around implementing a config mechanism shared with core and using json/yaml instead of ini. |
This PR implements CLI argument parsing and a configuration file for Grist Desktop. Partly addresses #25 and closes #27.
Also includes changes to rename grist-electron to Grist Desktop.