Skip to content
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

ESModule plugins #2

Open
tomasklaen opened this issue Jun 5, 2021 · 2 comments
Open

ESModule plugins #2

tomasklaen opened this issue Jun 5, 2021 · 2 comments

Comments

@tomasklaen
Copy link
Member

tomasklaen commented Jun 5, 2021

Drovp plugins, or at least the main files loaded by the renderer, currently have to be in CommonJS module format, because Electron still can't import() ES modules (electron/electron#21457).

You also can't use dynamic import() inside the main files to load npm ES modules, because the import() you're seeing there is the front-end browser version of the import(), which can't resolve npm module identifiers. The node import() is not available to the Electron renderer process (see the issue linked above).

There is also a separate issue that ES modules don't have any cache busting mechanism, so it is normally impossible to reload them (what a huge spec oversight imo), but I was able to solve this problem. It's not an ideal solution, a bit hacky, but I can't use it anyway because of how behind the curve Electron is.

So, we are essentially waiting for electron/electron#21457


That being said, all of the above only affects the main plugin file which is loaded by Electron renderer process to extend Drovp UI. The processor files can already be ES modules, or import ES modules with dynamic import() calls, as processor files are running in a raw node processes absent of Electron shenanigans.

Jut save the processor as .mjs and you are good to go.

EXCEPT when using typescript, where setting up different compilation configuration for each file (main has to be compiled into commonjs, and processor into esm) can get a bit messy. I'm currently solving it by just compiling everything to commonjs, and inside a processor using this helper:

const nativeImport = (name: string) => eval(`import('${name}')`);

To get an access to native import(), since Typescript in commonjs mode compiles import() statements into require()s and it can't be turned off. I loose types tough :(

If someone knows a nicer way how to set up a TS project for this kind of environment, I'm all ears. It has to be able to have a simple npm start script that spins up a continuous (watched) compilation for all files.

@tomasklaen
Copy link
Member Author

Since Drovp 0.8.0 (built with Electron 28 which adds ESM support) this might not be an issue anymore, but I haven't tested it extensively yet.

@tomasklaen
Copy link
Member Author

After testing it today, I just confirmed what the electron already documented: loading ESM modules from Electron's renderer process is still not possible, and probably won't be in any near future :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant