Open bradzacher opened 5 hours ago
Essentially a duplicate #29631, #52127. TS intentionally outputs private members without a type in declarations. I imagine the pattern of using indexed access of private members for declaration files is not supported.
To preempt the question as to why this doesn't use parameter properties, the actual code looks more like this:
export class Foo {
private _property: string;
constructor(opts: { _property: Foo['_property'] }) {
this._property = opts._property;
}
}
I imagine the pattern of using indexed access of private members for declaration files is not supported
To be clear -- I'm 110% fine if it is an intentionally not supported pattern!
However it should really be a semantic error to do this with declaration: true
.
There's a massive footgun that exists here and it's very opaque to try and debug the weird behaviour and bugs that come from it.
If TS errored letting you know that this was going to generate an any
then you'd know not to do this and to instead extract the type to an alias and reuse it, or to copy+paste the type.
🔎 Search Terms
class private any index access
🕗 Version & Regression Information
⏯ Playground Link
https://www.typescriptlang.org/play/?#code/KYDwDg9gTgLgBAYwDYEMDOa4DEITgbwCg4S4woBLANxRmDgH1yIxhYBPALjjRkoDsA5nAC8cAOTiA3MVIII-XlACuCGNAAUKKIO44IAbXFMoLNjHbiAugEoCskgF9CzoA
💻 Code
🙁 Actual behavior
Generated
.d.ts
is:🙂 Expected behavior
Generated
.d.ts
is:Additional information about the issue
This behaviour is problematic because it creates a desync between consumers of
.ts
files and consumers of.d.ts
files for the same code.For example:
If the
Foo
type comes from the.ts
file, then TS will error on this code as it can see that the argument type isstring
. OTOH if theFoo
type comes from the.d.ts
file, then TS will NOT error on this code as it sees the argument type asany
.We have just uncovered this at Canva. A user reported an error showing up in their IDE against our
master
branch (i.e. code that has passed CI as typechecked). The code is structured such that the file with the error (A) is in a separate project to the file declaring the class (B). This means that we have the exact scenario above where (A) consumes (B)'s.d.ts
during our CLI builds, but (A) consume's (B)'s.ts
within the IDE.This pattern of declaring a type based on a private property's type is quite pervasive across our codebase and it's surprising that this is the first problem that's been actively revealed.