Skip to content

Update NoResolution.md #174

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jul 5, 2024
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
6 changes: 3 additions & 3 deletions docs/problems/NoResolution.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ Import failed to resolve to type declarations or JavaScript files.

This problem indicates that TypeScript can’t find any file with a supported file extension (`.js`, `.mjs`, `.cjs`, `.jsx`, `.json`, `.ts`, `.mts`, `.cts`, `.tsx`) by following its own resolution algorithm, or a modified version of its resolution algorithm that ignores type declaration (`.d.ts`, `.d.mts`, `.d.cts`, `.d.*.ts`) files (which allows it to find JS files it would otherwise ignore).

## Consequnces
## Consequences

* Consumers will see TypeScript errors on imports/requires.
* If the diagnosis is accurate, a runtime/bundle-time error will occur.
Expand All @@ -15,7 +15,7 @@ This problem indicates that TypeScript can’t find any file with a supported fi

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

☝️ There's another one -- "Consequnces" -- would you mind including that? I was just about to open a PR myself, but since you're already on it 😎

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch. thanks

### False positive: unsupported file extension

TypeScript doesn’t record non-JS/TS files as resolution results, and its API can’t be used to distinguish between a result with an unuspported file extension and a non-existent file. If a package.json subpath exposes a non-JS asset like a `.css` file, designed to be processed by a bundler or runtime extension, this will show up as a failed resolution, when it might be more accurately described as an [untyped resolution](./UntypedResolution.md) of an unknown file type.
TypeScript doesn’t record non-JS/TS files as resolution results, and its API can’t be used to distinguish between a result with an unsupported file extension and a non-existent file. If a package.json subpath exposes a non-JS asset like a `.css` file, designed to be processed by a bundler or runtime extension, this will show up as a failed resolution, when it might be more accurately described as an [untyped resolution](./UntypedResolution.md) of an unknown file type.

If the asset is intended to be imported as a side-effect import (`import "pkg/styles.css"`), this problem can safely be ignored.

Expand All @@ -36,4 +36,4 @@ 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.
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.