esm: allow configuring default package type

[bmeck]

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

This is purely to allow people make builds that play around with the idea of changing the default package type, per comments in #32316 . This breaks many expectations and likely should not be done as a runtime flag for now (e.g. the test suite for node cannot run if this this is set to module).

[MylesBorins]

Should switching this flag change the name of the binary? Is there a current flag to do so?

I think it might be prudent to not call the binary that is build with this node, I personally would prefer esnode

[bmeck]

i think node-$mode would be fine, i don't think such a behavior exists currently

[MylesBorins]

I won't block this PR but I think it would be prudent to force this config option to reconfigure the binary name or we are likely going to get all sorts of weird errors happeninng

[GeoffreyBooth]

This is purely to allow people make builds that play around with the idea of changing the default package type

I appreciate that you're making this nearly inaccessible to the average user, but why include it in the Node codebase at all? What's the value in a special extra option for someone building their own Node binary? (Not saying there isn't one, but please explain it to me.)

Two issues that occur to me:

1. Package managers might start shipping an alternate version of Node that's compiled differently. For whatever reason, the Debian maintainers have been shipping their own custom-patched version of CoffeeScript for years now: https://sources.debian.org/patches/coffeescript/1.12.8~dfsg-4/. Granted anyone can do anything with an open source project, but it's just something to be aware of. All the more reason to implement @MylesBorins' suggestion of forcing a different binary name.

2. What about node_modules? Is there a way to limit the “default package type is module” to stop at a node_modules boundary? Or should we just assume people need to use a script to add "type": "commonjs" recursively to all their "type"-less dependencies under node_modules?

cc @nodejs/modules-active-members

[guybedford]

As per the discussion, I'd like the public aspect of "type": "none" to not be exposed here.

[guybedford]

Can we just make the default "commonjs" instead of "none" since that is what we've defined to be the default.

[guybedford]

This defaultPackageType implementation can move into the getPackageType implementation itself. Alternatively getPackageType can return eg undefined to indicate the default should be used.

I just want to avoid explicitly supporting a new "type": "none" value in the public API.

[ljharb]

This seems like a very dangerous thing to enable; i recall that the modules group explicitly decided not to do this with discussions around the type flag in the first place.

[jkrems]

I support this as a build-time flag. I don't think anybody expects this to become something supported by node anytime soon. I'm fine with keeping the name as node. This isn't a build people should have in their PATH long-term. Making that easier, makes it more likely that people do start depending on this feature.

I'm not really concerned that a popular distro would include this (especially if it doesn't affect the binary name). It'll break every node.js user and/or program in the distro. If we want to be explicit, we could name the flag something like --unsupported-and-not-recommended-default-package-type.

What about node_modules? Is there a way to limit the “default package type is module” to stop at a node_modules boundary? Or should we just assume people need to use a script to add "type": "commonjs" recursively to all their "type"-less dependencies under node_modules?

I don't think this is meant to be a realistic feature that people can use right now. It's meant as a playground. Making it easy to use "successfully" is an anti-goal since it may mislead people into thinking this is a build variant we officially support or encourage.

Package managers might start shipping an alternate version of Node that's compiled differently.

I don't think this PR makes this any more or less likely. If they really wanted, they could float a patch to change the default and it would be fairly maintainable to do so. Maintainable as in "keep the patch functional over time".

[...] why include it in the Node codebase at all? What's the value in a special extra option for someone building their own Node binary?

To me the value here is that we have an accessible build with this behavior. PRs and patches bit rot pretty quickly, especially for the module loader code. And by making it a build flag there's a sufficiently high bar that I wouldn't expect it to spread.

[ljharb]

Ah, i misunderstood that this is a build time, not a runtime flag; that makes it less dangerous, but I’d still prefer it not to exist; since they can float a patch to “play”, why do they need any more support than that?

[bmeck]

In the modules WG meeting we came to a conclusion that we have no intent to change the default package type in the foreseeable future. Given that stance, and that this PR would introduce effectively dead code without the ability to maintain tests for it because of requiring a separate build I will be closing it. If anyone wants to float a patch with the changes made in this PR they can do it on their own fork for now.