-
Notifications
You must be signed in to change notification settings - Fork 44
Feature: Provide a way to make ESM the default #318
Comments
can you remove --eval from this? i think it should use repl mode (assuming repl mode moves forward) which would remove it as an issue for us entirely. |
Wouldn’t that be a breaking change for If |
I wrote a hypothetical ecosystem migration strategy here:
|
See #335 (comment) |
Some users will want to rush forth into the ESM-only future and work with Node as if ESM were the default instead of CommonJS.
Use cases
Loose extensionless or
.js
files that contain ESM syntax, where the user doesn’t want to use @WebReflection’s clever shell scripting or create symlinks to.mjs
files or.js
files inside an ESM package scope.More convenient
--eval
or--print
, e.g.node -e 'import "foo"'
rather thannode --input-type=module -e 'import "foo"'
.Implementation
I’m assuming that the general way to do this would be to introduce a new flag to go in
NODE_OPTIONS
. I think a logical name would be--default-type
and it would takecommonjs
ormodule
, just like--input-type
. The question is what the behavior of--default-type
should be:It could set the default mode for
--input-type
and stop there. This would solve the second use case but not the first.It could do the above and also set the default mode for files outside of any package scope (i.e. Node crawls all the way up to the volume root without finding a
package.json
to govern the file). This would solve both use cases.It could do the above and also set the default mode for the package scope around initial an entry point. In other words, a user’s project with no
"type"
field would be treated as ESM, but any dependencies in that project’snode_modules
that lacked a"type"
field would still be treated as CommonJS. This would provide the most feeling like ESM was the default to be opted out of rather than into, without breaking all over the place if it also applied to dependencies. I don’t know what the use case for this would be, though; adding"type": "module"
to apackage.json
doesn’t seem like such a burden that we need a flag to opt out of needing to do that.It could do the above and also set the default mode for all package scopes that lack a
"type"
field. This would flip all defaults, everywhere that CommonJS is currently defaulted to, but projects would be broken until all dependencies had a"type"
field declaring themselves to be either ESM or CommonJS (or a package manager added such a field automatically). There’s no use case for this either that I can think of, though it’s the most “pure” in that it would show what a future Node would be like where CommonJS were deprecated.The text was updated successfully, but these errors were encountered: