Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions docs/problems/NoResolution.md
Original file line number Diff line number Diff line change
Expand Up @@ -37,3 +37,6 @@ When this problem occurs for the `node10` resolution option but not any others,
In this example, an import of `"pkg/subpath"` can be used in Node 12+ and modern bundlers, but would fail to resolve in Node 10. Accordingly, TypeScript’s `--moduleResolution node10` (also confusingly known as `node`, because history) does not resolve `"exports"` either.

While few libraries care about supporting a long-past EOL version of Node, maintainers of very popular libraries should be aware that many TypeScript users are still using `--moduleResolution node`. If they aren’t literally using Node 10, they really should move away from it, but sometimes migrating can be difficult because it introduces new errors caused by _incorrect dependency typings_—the problem this tool was made to diagnose. Popular libraries often choose to adopt a strategy that allows `--moduleResolution node10` to work even without `"exports"` support. https://github.com/andrewbranch/example-subpath-exports-ts-compat demonstrates several such strategies.


> You can use the [`--profile node16` option on the CLI](https://github.com/arethetypeswrong/arethetypeswrong.github.io/tree/main/packages/cli#profiles) to ignore issues that only affect `--moduleResolution node10`.