Closed benbucksch closed 1 month ago
Better contentmenu: https://github.com/alex8088/electron-uikit/tree/main/packages/contextmenu
Better contentmenu: https://github.com/alex8088/electron-uikit/tree/main/packages/contextmenu
FYI: These do different things. This implements the menu widget, but not the menu items, i.e. which items apply to the context, the JS function that implements the functionality, and the label and icon. electron-context-menu
implements the latter, not the former.
@alex8088 Hey Alex, we managed to change the complication of the main and render process scripts (src/main/index.ts
and src/renderer/index.ts
) to pure ESM, solving this issue:
https://github.com/mustang-im/mustang/commit/c426b1948e946127b2d39fd2e97f83558727f1a2
Would it be a good idea to change the quick-start
template to default to ESM instead of compiling to CommonJS? I understand why CommonJS was the default a few years ago, but now basically everybody (esp. with Svelte) uses pure ESM. It's a pity to compile this down to CommonJS.
This is esp. true given that quick-start
is meant for new projects, so you don't have to worry a lot about legacy code. And the projects started now might be existing for years to come with that template code. They'll be stuck with CommonJS, unless the project developers dig into it, understand that it's compiled to CommonJS (this wasn't clear to me until this bug - I thought we were using ESM only), and find the right solution. All others will continue to use CommonJS.
So, isn't it better to use the new/future/standard technology for new projects?
Yes, we followed these instructions to activate ESM support. However, that requires all developers to a) know that their code is recompiled as CommonJS and b) manually make these changes. It took us significant amount of time to debug this problem. I never would have thought that our ESM code is downconverted by the build scripts to CommonJS. Without knowing all the details, it's surprising that the import of an ESM package from our purely ESM code is failing.
This bug is about making ESM is enabled by default in the quick-start
, see my last 2 comments.
Project setup
.ts
file extensionimport
everywhere in our code. We do not userequire()
anywhere in our code base.Reproduction
npm create @quick-start/electron@latest
cd electron-app; yarn install; yarn run dev
-- worksyarn add electron-context-menu
, andimport
it to main.ts, as shown below.yarn run dev
Note: This is an ESM-only (!) third-party npm library, not built by me. The problem is not limited to this library. I have seen the same error multiple times in the past, with different libraries. It appears to be a generic problem with vite in combination with ESM-only modules.
Actual result
Expected result
(and actual result before adding
electron-context-menu
)Code
Reduced code of the e2/src/main/index.ts file:
You find the rest of the files, including the build config files, at https://github.com/mustang-im/mustang/tree/4fc959d/e2
Error
Fix attempts
What I tried to fix it:
require()
at all. Very confusing and misleading error msg. I suspect vite converts theimport
into arequire()
?type: module
in e2/package.json (of the electron app) - same result. Does not fix it.Rejected solutions
What I consider a bad fix with other disadvantages and what I do not want to do:
import()
, because completely unnecessary here.Possible solutions
What I could imagine might work:
import
/ESM code instead of transpiling intorequire()
code.Used Scaffolding
create-electron
Used Package Manager
yarn
Validations