-
Notifications
You must be signed in to change notification settings - Fork 4
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
.mjs files inside CommonJS packages #5
Comments
Migrated from nodejs/ecmascript-modules#19 (comment): My concern is that if this is allowed, there’s no certain way for Node to determine the parse goal(s) of a package. In the proposal as written, a package needs a |
The proposal doesn’t change the fact that Allowing From a UX perspective, one could argue that since |
Why wouldn’t we want to allow it? The file alone should be sufficient; imposing a forever tax on dual packages seems like a very bad idea. |
People will want to write We wouldn’t want to allow it for the reasons I’ve listed:
|
People will also want to both import from I'm still not clear on where this "exports" field is necessary - if "main" is "index", then |
This proposal is based on the package exports proposal, not on |
Since we want to encourage browser-compatible code ( The exports proposal does allow |
Migrated from #4 (comment) and following comments; and nodejs/ecmascript-modules#19 (comment) and following comments.
@guybedford: Having
import 'cjs/subpath.mjs'
not work seems overly restrictive to me, where users that have already been writing mjs might expect it to work within CommonJS packages.The text was updated successfully, but these errors were encountered: