If we use nodenext/node16 we can ship any kind of module within 1 package thus bundler ( compiler ) cannot determine properly how a file should be transpiled.
As we use explicitly .mts we say that those files are 100% native ESM which typescript will properly enforce and understand. then we can use module EsNext instead which will properly adhere to bundler (tsc executor) logic without any patches needed.
Alternatives
keep "moduleResolution": "NodeNext",
explicitly specify path to index.d.mts within outputs:
still will need to patch tsc executor to resolve to esm. (what about using swc executor -> that will fail short with .mts/.mjs extensions -> migration to .js/.ts would be required
override moduleResolution/module per library within tsconfig.lib.json
Sidenotes/questions:
wondering why the approach of going with .mts/mjs extension instead of type:module and using .js/ts extensions everywhere as default
New behaviour
While TS docs recommends to use node16/nodenext for any nodejs application code that support node>12, it doesn't provide any guarantees for bundler.
If we use nodenext/node16 we can ship any kind of module within 1 package thus bundler ( compiler ) cannot determine properly how a file should be transpiled.
The main source of truth is file extension or
type
field within package.json.As we use explicitly
.mts
we say that those files are 100% native ESM which typescript will properly enforce and understand. then we can use moduleEsNext
instead which will properly adhere to bundler (tsc executor) logic without any patches needed.Alternatives
"moduleResolution": "NodeNext",
index.d.mts
withinoutputs
:tsc
executor to resolve toesm
. (what about using swc executor -> that will fail short with.mts/.mjs
extensions -> migration to.js/.ts
would be requiredtsconfig.lib.json
Sidenotes/questions:
wondering why the approach of going with
.mts/mjs
extension instead oftype:module
and using.js/ts
extensions everywhere as default