You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/problems/NoResolution.md
+3Lines changed: 3 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -37,3 +37,6 @@ When this problem occurs for the `node10` resolution option but not any others,
37
37
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.
38
38
39
39
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.
40
+
41
+
42
+
> 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`.
0 commit comments