Exported types require the lib user to have "moduleResolution": "nodenext"

[nayeemrmn]

If your library has an exported subpath such that the following package.json is generated:

{
  "exports": {
    "./subpath": {
      "import": "./esm/subpath/index.js",
      "require": "./script/subpath/index.js",
      "types": "./types/subpath/index.d.ts"
    }
  }
}

A user of this lib who is using TS will find that the "types" field above will not be used unless they have "moduleResolution": "nodenext" or "moduleResolution": "node16" in their tsconfig. (In practice this only affects subpaths require("my-lib/subpath") because the top-level "types" field will be looked up for the main entrypoint.). The issue relates to us specifically because dnt forces explicit exports.

Should we open an upstream issue for TypeScript to apply package.json:exports["./subpath"].types resolution even for "moduleResolution": "node"? The current restriction isn't explicitly is mentioned in https://devblogs.microsoft.com/typescript/announcing-typescript-4-5-beta/#packagejson-exports-imports-and-self-referencing, it's categorised under "nodenext" support. But I think they'd be open to extending it to "node" because it's not breaking in practice.

Otherwise we just have to document the requirement that an npm lib generated with dnt requires the lib user to have "moduleResolution": "nodenext" in their tsconfig for subpath imports to be typed.