chore: switch to TS module ESNext with Node resolution

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 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:

"outputs": [
        "{options.outputPath}",
        "{options.outputPath}/src/index.d.mts"
      ],

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

microsoft / monosize