Discussion: Name of the flag for the “ESM by default” mode

[GeoffreyBooth]

Building off of #49432, what should the flag be named for this proposed new mode? Yes, this is the bikeshed thread.

I think we have a few constraints:

• Whatever we choose needs to begin with --experimental (for now, until it goes stable).
• It needs to either be a flag that takes a value, like our existing --input-type=module / --input-type=commonjs; or have an obvious opposite, so that if/when this new mode becomes the new Node default there’s some way to opt back into the previous CommonJS-first behavior.
• If it takes a value, those values should be module and commonjs for consistency with the existing --input-type and the package.json "type" field.
• We shouldn’t pick --experimental-module because there was a prior flag named --experimental-modules which still exists as a noop, and it would be confusing to users if nothing happens when they try to use the flag but made a typo.

Please vote using emoji:

• 🚀 --experimental-type=module / --experimental-type=commonjs
• 🎉 --experimental-default-type=module / --experimental-default-type=commonjs
• ❤️ --experimental-implicit-type=module / --experimental-implicit-type=commonjs
• 👀 --experimental-esm-by-default / --no-experimental-esm-by-default

[GeoffreyBooth]

I’ll start: --experimental-type=module / --experimental-type=commonjs.

[targos]

--experimental-type (--type when stable) SGTM. It's close to <script type="module">.

[Qard]

Maybe I missed some context somewhere, but why do we need another flag separate from --input-type? Can we not just aim to switch the default of that one?

[GeoffreyBooth]

Maybe I missed some context somewhere, but why do we need another flag separate from --input-type? Can we not just aim to switch the default of that one?

Because that one only affects --eval, --print and STDIN, and I'm proposing having it affect many more things. It would be a breaking change if we expanded the behaviors of --input-type.

[Qard]

Not clear why that would be considered a breaking change. If the flag was not supported in anything but those cases previously then this would just be a case of adding additional support, which sounds to me like a minor. 🤔

In any case, it sounds rather unfriendly from a usability perspective to have two different flags that sound like they do the same thing (Because they do! Just in slightly different contexts.) rather than sticking to the one flag we already have that does this. ESM is already confusing enough with all the extra configs and inconsistencies with CJS-derived expectations, we don't need proliferating flags adding to the complications. 😬

[GeoffreyBooth]

Not clear why that would be considered a breaking change.

Well, maybe it wouldn’t be. Currently if you run node --input-type=module test.mjs it throws Error [ERR_INPUT_TYPE_NOT_ALLOWED]: --input-type can only be used with string input via --eval, --print, or STDIN. So it would no longer throw in this case, which maybe isn’t breaking?

Perhaps the better question is whether we would still need --input-type in the new mode. Like say we ship --experimental-type; would there be a reason to ever run node --experimental-type=module --input-type=commonjs ...? I guess maybe if you want an --eval string that’s CommonJS, but also want any files on disk that it may reference to be treated via the ESM-first semantics. Not sure when you would want this, but it’s at least a potential use case.

A simpler way to put it: if --experimental-type=module becomes the new Node-wide default, would there be any reasons to run node --input-type=commonjs rather than node --type=commonjs?

[Qard]

I think that's a case of "Just because you can doesn't mean you should." Yes, theoretically that may be a case a user may try to do, but is that something we want to actually support? Or should we just have a switch on all cases? Seems to me a lot less confusing to just have a process wide switch of everything from CJS mode to ESM mode.

[GeoffreyBooth]

is that something we want to actually support?

No, unless there’s a plausible, reasonable use case. Which there may very well be! That’s my question, can you think of one?

[Qard]

I would rather not support it until someone asks for it than try to invent some scenario that a user may never actually do. It's a lot easier to add support for something than it is to remove it. We should be very intentional and feedback-driven by things like that.

[GeoffreyBooth]

Well except that in this case it’s hard to add support for it if we’ve already redefined --input-type.

I think if we want to potentially use --input-type and enlarge the scope of what it covers, the way forward would be to create a temporary new flag --experimental-input-type that has the broader set of behaviors; and when we’re ready to call it stable, we move those behaviors down into --input-type. What do you think?

Alternatively we create --experimental-type and eventually --type, and deprecate (maybe just docs deprecate) --input-type.