What should the new `moduleResolution` setting be called?

[andrewbranch]

I’m looking for community feedback on the naming for #51669. For the full background on that PR, read #50152.

The short version is that it’s mostly designed for bundlers, but is also appropriate for runtimes like Bun, especially those that understand TypeScript natively. I initially wanted to avoid a very specific name like bundler that could prove to be a bad name in a few years if, say, a new wave of bundlers takes a very different approach to module resolution, or a new wave of runtimes are well-suited for the mode, or a huge number of projects use all-in-one frameworks like Next.js that are also well-suited for the mode but make it difficult to recognize what bundlers and runtimes and resolution features are actually in use.

The name I first proposed in #50152 was conventional, because it attempts to find the common ground shared by all the popular non-Node, non-Deno resolvers I surveyed. There was some concern that this could be read as a snub to Node, Deno, and other resolvers that implement strict resolution rules for ESM, so I revived hybrid from #29353. Both names are intentionally vague, but I’m rethinking whether that’s a good idea.

One potential mitigation for the name becoming a poor fit due to unpredictable future events is simply tacking the year onto the end: bundler2022. I don’t love this because if it turns out to be long-lived with the help of small, backward-compatible changes, it will falsely appear to grow increasingly outdated.

Let me know your thoughts and suggestions. 🚲🏠

[MartinJohns]

I vote for BundlyMcBundlerface.

[ljharb]

From reading the recommended issue, it's still not clear to me what the target is, besides bun/esbuild.

I think that it's reasonable to have resolution modes that match platforms:

• node
• browser
• deno
• whatever else is popular enough to warrant inclusion

but also to have modes that match what users expect:

• "what babel does", which i suspect by a large margin is what users expect
• esbuild/bun
• whatever else goes here

Are there more tools/bundlers that would use the proposed new mode that I missed?

[andrewbranch]

Webpack, Parcel, Browserify, maybe Rollup (they call into us for resolution so it’s debatable), Vite, Next.js I think, which uses swc.

Babel does module resolution? I thought it only needs to care about one file at a time, specified via glob or something?

[ljharb]

Babel transpiles to CJS, so it allows ESM to be authored omitting extensions, and "index", and it ends up working the same.

If it's all bundlers, then I think "bundler" is probably the right key - the only way that term would stop being accurate would be if the majority of bundlers all switched to something new - and there'd probably be a new term we all associated with that new thing anyways that would help you name the new mode.

[fatcerberus]

In that case, "what babel does" reduces to moduleResolution: "node" (i.e. pre-ESM Node resolution behavior).

[andrewbranch]

If we’re splitting hairs, what Babel does is orthogonal to moduleResolution. The moduleResolution setting you should choose to check your code that you’ll later compile with Babel depends entirely on where you intend to run that CJS code. moduleResolution is only concerned with the things in your toolchain/runtime that actually consume module specifiers and perform resolution to take some action on the target module. The caveat is that if, as in Node, resolution happens differently depending on import/require syntax, file extension, and package.json scope, then TypeScript may need to understand that a transformation of import syntax is going to happen. So in the example of running code transpiled with Babel in Node 12+, you would want to choose moduleResolution: "nodenext" while ensuring that your package.json "type" is unset or set to "commonjs", so that TypeScript will understand that the import syntax will ultimately become a require. This all works out only because Babel will produce roughly the same JS that tsc would under these settings—TypeScript doesn’t know you’re using Babel or what Babel will do, but it’s sufficiently close to what tsc will do that the checking works out. But it would be wrong to use moduleResolution: "node" in this case, because that mode lacks support for package.json exports. So if you write an import of some package that Babel turns into a require of some package and then run that require in Node, Node will consult that package’s exports if it exists. If that lookup resolves to a different result than the main would have pointed to, then likewise you would get an incorrect resolution of types for that import under moduleResolution: "node". (To help clear this confusion up, I plan to rename node to node10 after #51669.)

[Faithfinder]

If this targets bun/rebuild you could name it both as an alias, and tack on a year anyway.

[johnnyreilly]

Have you considered conventionalnext 😅

To be honest, hybrid doesn't feel like a great name as it doesn't convey any particular meaning. Is it for the browser? Don't know. Is it not for the browser? Maybe?

How about runtime? I think the idea is that this setting covers multiple runtimes including node, deno, bun etc. And bundlers are invoked by a runtime (typically node but that may change).

In my mind the advantage of runtime is that it conveys some information of where it might be used

And if you wanted to hedge your bets: runtimenext

And if you want internet points: runtimeyMcRuntimeFace

[fatcerberus]

If you're targeting a bundler, moduleResolution: "runtime" is inaccurate because where your code is ultimately run doesn't matter - the bundler does all module resolution, which in turn depends on the particular bundler, not the runtime it happens to run on. That's what this setting is about - it's not about where your code is being run, but instead which part of your toolchain resolves your module specifiers.

[robpalme]

I think the shared heritage for the new mode is that it captures descendents/specializations of a Node-like approach. It represents some kind of lowest common denominator for mainstream use today, which also means it omits some of the features of latest Node. Here are some suggestions:

• node-based (dual use of "based")
• node-compatible
• node-minimal
• node-like
• node-ish
• nodey (I genuinely like this)

All of these escape the value judgements of conventional and vagueness of hybrid. It's no more or less of a snub to Node or non-Node resolvers than today's situation in which they are forced to use node.

[DanielRosenwasser]

What do people think about nodey-mcnodeface?

[fatcerberus]

Okay I’ll bite - is this a recent meme I’m not aware of?