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

Breaks when importing a module that uses ESM #329

Open
TaylorBeeston opened this issue Dec 10, 2021 · 4 comments
Open

Breaks when importing a module that uses ESM #329

TaylorBeeston opened this issue Dec 10, 2021 · 4 comments

Comments

@TaylorBeeston
Copy link

In Meteor 2.3+, importing a module that uses esm causes the server to crash with a module.export is not a function error.

I have made a minimal reproducible example here.

In that repo, I have tested and verified that Meteor 2.2.4 (the last release before Node 14) works, and 2.3 and above crash with that error.

Interestingly, this error only happens if you import an ESM package in server-side code, not on client-side code.

I imagine this issue was created by Node 14 natively supporting ESModules, but I don't have a deep enough understanding of Meteor/Reify to be able to offer any kind of fix =/

@benjamn
Copy link
Owner

benjamn commented Jan 31, 2022

@TaylorBeeston I'm no longer actively working on Meteor, but my advice to the team would be to start thinking about how the Meteor CLI can take advantage of compiling down to native ESM modules, instead of CommonJS. I'm not sure the end-to-end story is quite there yet, but it's certainly much further along than when I last worked on this stuff. Deno may be a good example to follow, though Deno is not based on Node.js. My personal bias: if I were rebuilding Meteor from scratch today, I would pick Deno as the underlying JS environment, rather than Node.js.

In the meantime, you should be able to recompile specific npm packages (to make their ESM code compatible with Node/CommonJS/Reify) using this configuration in your package.json file. You probably don't want to enable this for all npm packages in node_modules, since any work that touches (or even looks at) the entire contents of node_modules tends to be pathologically slow for large projects.

@trusktr
Copy link

trusktr commented Feb 17, 2022

Choosing Deno would be a huge breaking change, and it will introduce dependency management difficulties without an out-of-the-box package manager.

you should be able to recompile specific npm packages (to make their ESM code compatible with Node/CommonJS/Reify) using this configuration in your package.json file.

Many third-party libs not written for Meteor aren't going to all start adding meteor sections to their package.json files, so this mostly won't work, except for Meteor users who also happen to publish libs to npmjs.com.

@edemaine
Copy link

edemaine commented Feb 17, 2022

Supporting a workaround package like esm seems debatable, but what would be really nice is for Reify to support the conditional exports feature in package.json. @benjamn is this something you'd consider reviewing in a PR? It would be greatly helpful for Meteor today. Also, any pointers for how to go about it would be helpful.

@trusktr
Copy link

trusktr commented Mar 16, 2022

Note, the esm package does not support package.json exports fields.

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

4 participants