types-versions-wildcards

types-versions-wildcards

Mode of operation

This strategy works very differently than the other two; rather than relying on file-system-based resolution features, it leverages typesVersions to reroute TypeScript’s --moduleResolution node resolution process in the same way that exports reroutes exports-supporting resolvers’ resolution process.

import "types-versions-wildcards/one";

An exports-supporting resolver will look up "./one" in the package.json exports, which in turn points to ./dist/one.js (or ./types/one.d.ts for TypeScript). Most non-exports-supporting resolvers will fail, but TypeScript under --moduleResolution node (which does not support exports) will look at the typesVersions map in package.json:

{
  "//": "...",

  "types": "index.d.ts",
  "typesVersions": {
    "*": {
      "*": ["types/*"]
    }
  }
}

The first * matches the TypeScript version, and the second matches (and captures) the package subpath, resulting in the substitution types/one, which is resolved relative to the package root and ultimately resolves to ./types/one.d.ts.

This has the same effect on TypeScript that the exports would have had on any resolver that used it, but typesVersions only affects TypeScript. This strategy does not help Node 11, Parcel, or Browserify users. This strategy should only be used by libraries that do not intend to support these users. This repository is intended to help library authors make informed decisions, not prescribe support.

Discussion

Pros:

• Simple
• Supports wildcards
• Can model subpaths that map to a file with a different name than the subpath
• Configuration maintenance is 1:1 with exports

Cons:

• Doesn’t support runtimes/bundlers that don’t support exports