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

require('some-es-package') does not fail as expected #325

Open
tniessen opened this issue May 1, 2019 · 2 comments

Comments

Projects
None yet
3 participants
@tniessen
Copy link
Member

commented May 1, 2019

First of all, thanks to all of you for your efforts! I am currently playing around with Node.js 12.0.0 and the new ESM implementation. One thing I have come across is that require('some-es-package') does not fail as expected if some-es-package has a package.json file containing these properties:

"type": "module",
"main": "index.js"

The call to require() fails with a syntax error whereas it becomes ERR_REQUIRE_ESM if I rename index.js to index.mjs. Is this behavior intended?

@GeoffreyBooth

This comment has been minimized.

Copy link
Contributor

commented May 1, 2019

See nodejs/node#27417 and #320.

The short answer is that the behavior of require with respect to ESM files and packages is still a work in progress.

@weswigham

This comment has been minimized.

Copy link
Contributor

commented May 3, 2019

The call to require() fails with a syntax error whereas it becomes ERR_REQUIRE_ESM if I rename index.js to index.mjs. Is this behavior intended?

Slightly more full answer: Yes and no. The behavior will likely change. It should ideally be ERR_REQUIRE_ESM in both cases, or not an error in either case. Moving from the (likely) parse error to the much nicer and more explainative ERR_REQUIRE_ESM error (or to not an error) hasn't really been seen as a semver breaking change, so fixing that up one way or another (which entails closing in on our final cjs interop strategy) hasn't been looked at much (sicne we're either just changing the text of a (likely) error to a better one or removing the errors entirely). In both cases, our logic for package-scoped configuration (for recognition of the type field) needs to get baked into the cjs resolver (as right now it is not) - our current implementation pretty much doesn't touch the cjs resolver, which is also why we just had to emergency patch in throwing on .mjs require's without the flag set.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.