Isolated declarations quick fix defaults to including renamed properties

[MichaelMitchell-at]

🔎 Search Terms

isolated declarations quick fix rename ts2842 ts9007

🕗 Version & Regression Information

• This is the behavior in every version I tried

⏯ Playground Link

https://www.typescriptlang.org/play/?isolatedDeclarations=true&ts=5.6.0-dev.20240807#code/KYDwDg9gTgLgBAMwK4DsDGMCWEWIBQCUcA3gFBwVxTAxJS5x57ECGAXHAEYC+HrHABm4EOANwiYAJnAC8APhLCAhAG5S3IA

💻 Code

export function f() {
    return  (({a: b}: {a: 0}): void => {})!;
}

🙁 Actual behavior

Quick fix introduces a type error:

export function f(): ({ a: b }: { a: 0; }) => void {
//                         ~
//                         'b' is an unused renaming of 'a'. Did you intend to use it as a type annotation? (2842)
    return  (({a: b}: {a: 0}): void => {})!;
}

🙂 Expected behavior

export function f(): ({a}: { a: 0; }) => void {
    return  (({a: b}: {a: 0}): void => {})!;
}

Additional information about the issue

While the quick fix is consistent with the emitted declaration, it ideally wouldn't lead to another type error which can be avoided.
There are cases where it may make sense to preserve the renaming, most obviously

export function f(): ({ a: b }: { a: 0; }) => typeof b {
    return (({a: b}: {a: 0}): typeof b => b)!;
}

but also perhaps

export function f() {
    return  (({a: b}: {a: 0}, a: {}): void => {})!;
}

though, maybe surprisingly, this would currently this still result in ts(2842)

export function f(): ({ a: b }: { a: 0; }, a: {}) => void {
//                         ~
//                         'b' is an unused renaming of 'a'. Did you intend to use it as a type annotation? (2842)
    return  (({a: b}: {a: 0}, a: {}): void => {})!;
}

Perhaps this could be relaxed. While b is unused in the direct sense, it technically has value in that it avoids the naming collision between the as.

[jakebailey]

IIRC we've tried to fix this particular thing multiple times now (at least for declaration emit), and have ended up just reverting all of the code that tries to elide these as the effort was just far too error-fraught.

See also:

• Binding element alias is kept even though it is unused in declaration files #55654
• Perform usage analysis on refenced binding aliases in function signatures. #55683
• Removing binding aliases causes duplicate identifiers in declarations. #56991
• Binding element alias is kept in function expressions even though they are never used in declaration files. #56992
• Do not remove binding alias in function declarations #57020

Maybe we can do better in the quick fix? But, then the quick fix would produce a result that differs from declaration emit via inference. It just seems like exactly the same problem space.