Repository navigation
Does it make sense to allow module: nodenext + moduleResolution: node? #48854
Description
Activity
So it is technically a useful configuration - we won't detect any esm files (since the resolution mode is pre-esm), but we will use the new cjs transform (ie, leaving dynamic import alone) on all the input modules.
To make a long story short
module moduleResolution uses package.json:type unset "node12" true "node12" unset true "node12" "node" false If you had a simple table like that (possibly with more entries) next to the documentation for both module and moduleResolution, I think it would prevent unnecessary confusion.
That is apart from the question of whether that combination should be allowed
Reacted by Simon Hammes, EviSONG, Tao, Jane Jeon and Alexandr Spiridonovthe moduleResolution option naming is bad,
classic&nodeis well documented on page https://www.typescriptlang.org/docs/handbook/module-resolution.htmlbut not node12/nodenext(now node16/nodenext), and not updated on tsconfig reference page
the
node12/node16/nodenextshould be renamed tonode-esmand points a link to the Node.js ESM resolve spec https://nodejs.org/dist/latest-v16.x/docs/api/esm.html#resolver-algorithm-specificationStrongly disagree. The TSConfig reference docs should change.
node16/nodenextis the only correct module resolution option if you are targeting Node 16+ (really 12+ with some caveats about async/await and certain package.jsonexportsfeatures).node16/nodenextdo not imply that everything uses ESM resolution; they simply correspond to versions of Node where ESM is available side-by-side with CJS. The resolution algorithm switches between CJS (more or less what you get all the time in--moduleResolution node) and Node’s new ESM resolver algorithm based on the input type that Node will see for the given import, which varies based on package.jsontype, file extension, and import syntax. Even if you are using exclusively CJS source and dependencies in Node 12+, using--moduleResolution nodewould be incorrect because it doesn’t respect package.jsonexports, while CJS resolution in Node 12+ does. Eventually, I would like to renamenodeto something that implies it’s only suitable for legacy code.Reacted by Sixian LiReacted by Jan Molak
In #48835, a user ran into an issue where the combined options were questionable. It seems like an innocent mistake, and by all means
moduleResolution: nodesounds compatible withmodule: nodenextormoduleResolution: node.Should we issue an error in some of these cases?
CC Wesley Wigham (@weswigham) Andrew Branch (@andrewbranch)