-
Notifications
You must be signed in to change notification settings - Fork 214
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
Core electron + core backend ESM #7293
base: master
Are you sure you want to change the base?
Conversation
@@ -39,7 +52,7 @@ | |||
"@itwin/core-bentley": "workspace:^4.10.0-dev.30", | |||
"@itwin/core-common": "workspace:^4.10.0-dev.30", | |||
"@itwin/core-frontend": "workspace:^4.10.0-dev.30", | |||
"electron": ">=23.0.0 <34.0.0" | |||
"electron": ">=28.0.0 <34.0.0" |
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.
what happens if we leave the min ver as is?
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.
Electron "properly" supports ESM from version 28. If we're delivering both CJS and ESM, we could leave version 23 as minimum, I think.
"build:cjs": "tsc 1>&2 --outDir lib/cjs", | ||
"build:esm": "tsc 1>&2 --module ES2020 --outDir lib/esm", |
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.
yourec ompiling core-electron to module esnext, but here es2020?
@@ -5,7 +5,7 @@ | |||
import { IModelRpcProps, RpcInterface, RpcManager, TextAnnotationProps, TextBlockGeometryProps } from "@itwin/core-common"; | |||
import * as http from "http"; |
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.
what are we using "backendServer" for?
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.
this shouldnt be in the common layer imo
"build:cjs": "tsc 1>&2 --outDir lib/cjs", | ||
"build:esm": "tsc 1>&2 --module esnext --outDir lib/esm", |
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.
Why deliver both CJS and ESM ? Wouldn't it be less painful to just switch to ESM on 5.0 ?
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, I was initially thinking this would go into one of the 4.X versions, but I'm now more certain this should be in 5.x - as I go through with modifying DTA, I'm noticing pain points with delivering dual cjs/esm, both in these packages and our electron-authorization pkg. When running an ESM module, and using named imports (like "@itwin/electron-authorization/Main"), electron complains at run time that it doesn't like electron-auth being CJS. And seems like the only way to solve that is to set 'type': "module" in the respective package.json.
Pausing work on this PR for now, but documenting the work so far:
|
ESM is not supported for preload script if sandbox is enabled (Electron ESM support matrix). If we plan to drop CJS from both backend and frontend code for Electron, we'll still need to transpile preload script to CJS. |
Isn't |
Notables:
Note: tsc does not add
.js
extensions to extensionless imports (unlike Vite :( ), so had to add.js
at the end of our relative import paths in DTA's backend.