Key Remapping in Mapped Types does not contribute to the reference of the original type
See original GitHub issueBug Report
Key Remapping in Mapped Types does not contribute to the reference of the original type
🔎 Search Terms
Key Remapping in Mapped Types does not contribute to the reference of the original type
🕗 Version & Regression Information
- This changed between versions
4.1
andnightly 20210616
⏯ Playground Link
Playground link with relevant code
💻 Code
const x = {a: 1, b: 2}
x.a
declare const y: {
[key in keyof typeof x]: boolean
}
y.a
declare const z: {
[key in keyof typeof x as `get_${key}`]: boolean
}
z.get_a
🙁 Actual behavior
x.a has references on line 2 and line 7
🙂 Expected behavior
x.a has references on line 2, line 7, and line 12
Rename x.a
to x.c
should rename line 12 to get_c
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (3 by maintainers)
Top Results From Across the Web
Key remapping breaks definition navigation for mapped ...
When using mapped type with key remapping, definitions for the properties of mapped types are no longer discoverable. Though, references are ...
Read more >Mapped Types with Key Remapping mixed in with other ...
So I am trying to do something like below with key remapping, passing in a second generic type optionally to spread out its...
Read more >Mastering TypeScript mapped types
In this post, we'll cover mapped types in TypeScript, a real-world example of them, and utility types including Partial, Readonly, and Pick.
Read more >keyof and Mapped Types In TypeScript 2.1
Both of these are syntax that sits on top of normal JavaScript to add type analysis — basically, a form of gradual typing...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
This turns out to be way harder than just a bugfix. The find-all-references code depends on being able to quickly reduce the set of candidate positions to look for based on the identifier tokens in each source file, but we don’t have any way to know that
get_a
should be counted as a reference toa
since this operation occurs syntactically before we have any type information.Thanks, that’s very helpful!