-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Proposal: Prioritize declaration file resolutions when declaration extension is explicitly specified #58700
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
base: main
Are you sure you want to change the base?
Conversation
… explicitly specified
@typescript-bot test top400 |
@andrewbranch Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
@andrewbranch Here are the results of running the top 400 repos comparing Everything looks good! |
Does this mean that any DTS file importing any relative specifier that ends with |
Yep, exactly. Could you explain how this would be useful for you? The motivation for this in #58353 is pretty narrow and specific. |
It's not for immediate use. And it's not something I'd pitch in isolation. But I'm happy to be a supporting voice. As a general rule, explicit/predictable/simple resolution behavior helps the long-term direction of making TypeScript more flexible/adaptable to custom JS environments. The opposite direction would be for TS have unavoidable implicit behavior, e.g. to bake-in popular conventions such as assuming some kind of extension-searching order, or assuming existence of a So this is just one instance of that wider choice. Explicit |
As a follow up, we just had a slightly more concrete instance of a situation where explicit resolution would have reduced confusion. As part of a migration to enable // main.ts
import { myType } from "../dir" // runtime error only when VMS enabled // main.d.ts (generated)
import { myType } from "../dir" // dir/index.ts
export type myType = string; This worked before // main.ts
import type { myType } from "../dir/index" We'd like to have a way to fix this confusion long-term by preventing index-resolution of types both in source and in DTS files via explicit extensions. That ensures that both humans and computers will not get confused about the meaning of an import. And may allow us to switch to a more appropriate TS resolution mode in future. // main.ts
import type { myType } from "../dir/index.ts" // main.d.ts (generated)
import type { myType } from "../dir/index.d.ts" |
Alternative to #58553
Fixes #58353