-
-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: upgrade electron to v22 #720
Conversation
getResourcesDir, | ||
getDefaultConfigDir |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
const label = path.basename(modulePath) | ||
|
||
// TODO: Used by renderer processes to determine if in development mode or not. There's probably a better way to do this | ||
window.mode = mode |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
mapServer = createMapServer(undefined, { | ||
database: new Database(path.join(mapsdir, 'maps.db')) | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe out of scope, but wondering if this should point to temp-resources
when in development, instead of the user data directory
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
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 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? |
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. |
in ci, electron build attempts to rebuild [email protected], which is only used as a dev dep. should potentially be okay to omit
for posterity, added |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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,.
Towards #715
Changes:
@electron/remote
electron-is-dev
because it no longer works in the renderer process as a result ofremote
removalecstatic
because of invalid shebang in source filereact-intl
to 6.2.8Questions:
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 changesreact-intl
if possible? (see above for details)Potential changes to make (either here or in a follow-up):
remote
apis.store.js
,client-ipc.js
,logger.js
, etc)