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

ESM error in v4 #7

Closed
yosbelms opened this issue May 11, 2021 · 2 comments
Closed

ESM error in v4 #7

yosbelms opened this issue May 11, 2021 · 2 comments

Comments

@yosbelms
Copy link

I get the following error when using [email protected]. The error is explicit, and offers 2 possible solutions.

Error: Must use import to load ES Module: /home/yosbel/Documents/experiments/procplay/node_modules/p-defer/index.js
require() of ES modules is not supported.
require() of /home/yosbel/Documents/experiments/procplay/node_modules/p-defer/index.js from /home/yosbel/Documents/experiments/procplay/.next/server/pages/_app.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /home/yosbel/Documents/experiments/procplay/node_modules/p-defer/package.json.
@sindresorhus
Copy link
Owner

Please read the release notes.

@joepie91
Copy link

joepie91 commented Jun 19, 2021

Running into the same issue here.

Unfortunately the instructions in the release notes effectively boil down to "use ESM instead of CommonJS" (the other two not being maintainable options), which is not an option for me as its a strictly inferior module syntax - as synchronous imports are now a special-cased statement rather than a first-class expression, it has become impossible to ergonomically implement patterns like parametric modules, which poses a significant maintainability issue. There are also many other issues.

I guess I just won't be able to use any of your modules anymore? It seems like a strange decision to intentionally break compatibility with many people's existing codebases (presumably the older branches won't get future updates), when it isn't actually necessary for any technical reason - your modules worked fine in both CommonJS and ESM environments when they were CommonJS exports.

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

3 participants