chore: upgrade electron to v22

[achou11]

Towards #715

Changes:

• Upgrade Electron to 22.3.2
  • Requires migration to @electron/remote
    • Requires changing usage of electron-is-dev because it no longer works in the renderer process as a result of remote removal
  • Upgrade map server to allow usage of better-sqlite3 > 7, which is required for this version of Electron
• Upgrade Node to 16.17.1 for dev environment, to match the version that Electron runs
  • Patches ecstatic because of invalid shebang in source file
• Upgrade react-intl to 6.2.8
  • Not sure if this was necessary but based on Upgrage Electron and Bundler #715 (comment), seemed necessary. (not sure how or if that note was related to Electron specifically though)
  • Can potentially revert this since it may be out of scope for the electron upgrade
• Fixes race condition issue with map server initialization when app starts for the first time
• Small removals/cleanups for unused things for development

Questions:

• Is it okay to use npm 8 instead of 6? how does that affect native builds if at all?
• What changes are needed in build.config.js to get things working? Seems like we do a lot of manual file picking in there so may need to update based on deps changes
• Should we revert upgrade of react-intl if possible? (see above for details)

Potential changes to make (either here or in a follow-up):

• Complete migration away from using remote apis.
• Improve usage of files that are used in different processes (e.g. store.js, client-ipc.js, logger.js, etc)

[achou11]

replaced the statically defined constants with these functions because this file is run in various contexts that are sensitive to the environment e.g. main process, background renderer, primary window renderer

[achou11]

window.mode is either "development" or "production" and is defined by a value passed to webPreferences.additionalArguments when creating a BrowserWindow in the main process

[achou11]

maybe out of scope, but wondering if this should point to temp-resources when in development, instead of the user data directory

[sethvincent]

yeah some kind of tmp directory would make sense. might be good to make an issue for it rather than deal with it in this pr.

[achou11]

yeah we already create a temp-resources which includes some assets like the presets. just a matter of whether it makes sense to put the maps db here during dev too

[achou11]

seem to be running into an issue with rebuilding native deps during electron-build in CI. link

Not entirely sure if it's because of using Node 16 + npm 8 or if it's an issue with a dep. Potential culprit dep seems to be fsevents@1.2.9, which seems to only be a dev dep (or at least only used by dev deps):

2023-02-08T20:36:34.5514150Z     npm ERR! In file included from ../fsevents.cc:6:
2023-02-08T20:36:34.5615460Z     npm ERR! In file included from ../../nan/nan.h:174:
2023-02-08T20:36:34.5716810Z     npm ERR! ../../nan/nan_callbacks.h:55:23: error: no member named 'AccessorSignature' in namespace 'v8'
2023-02-08T20:36:34.5817060Z     npm ERR! typedef v8::Local<v8::AccessorSignature> Sig;
2023-02-08T20:36:34.5918410Z     npm ERR!                   ~~~~^
2023-02-08T20:36:34.6018810Z     npm ERR! In file included from ../fsevents.cc:6:
2023-02-08T20:36:34.6120980Z     npm ERR! ../../nan/nan.h:2536:8: error: no matching member function for call to 'SetAccessor'
2023-02-08T20:36:34.6222610Z     npm ERR!   tpl->SetAccessor(
2023-02-08T20:36:34.6325020Z     npm ERR!   ~~~~~^~~~~~~~~~~
2023-02-08T20:36:34.6427110Z     npm ERR! /Users/runner/.electron-gyp/22.2.0/include/node/v8-template.h:814:8: note: candidate function not viable: no known conversion from 'imp::Sig' (aka 'int') to 'v8::SideEffectType' for 7th argument
2023-02-08T20:36:34.6527000Z     npm ERR!   void SetAccessor(
2023-02-08T20:36:34.6628160Z     npm ERR!        ^
2023-02-08T20:36:34.6730350Z     npm ERR! /Users/runner/.electron-gyp/22.2.0/include/node/v8-template.h:807:8: note: candidate function not viable: no known conversion from 'imp::NativeGetter' (aka 'void (*)(v8::Local<v8::Name>, const v8::PropertyCallbackInfo<v8::Value> &)') to 'v8::AccessorGetterCallback' (aka 'void (*)(Local<v8::String>, const PropertyCallbackInfo<v8::Value> &)') for 2nd argument
2023-02-08T20:36:34.6829690Z     npm ERR!   void SetAccessor(
2023-02-08T20:36:34.6930900Z     npm ERR!        ^
2023-02-08T20:36:34.7032310Z     npm ERR! In file included from ../fsevents.cc:6:
2023-02-08T20:36:34.7132950Z     npm ERR! In file included from ../../nan/nan.h:2884:
2023-02-08T20:36:34.7234660Z     npm ERR! ../../nan/nan_typedarray_contents.h:34:43: error: no member named 'GetContents' in 'v8::ArrayBuffer'
2023-02-08T20:36:34.7321430Z     npm ERR!       data   = static_cast<char*>(buffer->GetContents().Data()) + byte_offset;

wonder if there's a way to tell electron-builder to omit that (see relevant rebuild options here). @gmaclennan maybe you have an idea?

[gmaclennan]

There should be a way to omit builds for that? If everything is available as prebuild, then you can turn off build from source. But I haven't really got into the weeds of electron rebuilds so don't know a solution off the top of my head.

[achou11]

There should be a way to omit builds for that? If everything is available as prebuild, then you can turn off build from source. But I haven't really got into the weeds of electron rebuilds so don't know a solution off the top of my head.

for posterity, added fsevents as one of the native deps to remove in the remove-native-deps npm script (39fabc8). let's see if that works fine for our case...

[gmaclennan]

Looks ok to me. Frustrating that Electron keeps adding restrictions that makes simple stuff more complicated. If this works ok (I haven't tested it) then good to merge I think,.