Repository navigation
Using types from private class properties results in any types in .d.ts filesΒ #60230
Description
π Search Terms
class private any index access
π Version & Regression Information
- This is the behavior in every version I tried, and I reviewed the FAQ for entries
β― Playground Link
π» Code
export class Foo {
private _property: string = '';
constructor(arg: Foo['_property']) {
}
}π Actual behavior
Generated .d.ts is:
export declare class Foo {
private _property;
constructor(arg: Foo['_property']);
}π Expected behavior
Generated .d.ts is:
export declare class Foo {
private _property: string;
constructor(arg: Foo['_property']);
}
// or
export declare class Foo {
private _property;
constructor(arg: string);
}
// or
/* Typescript Errors on the code to tell you it's going to generate an `any` */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:
new Foo(1);If the Foo type comes from the .ts file, then TS will error on this code as it can see that the argument type is string.
OTOH if the Foo type comes from the .d.ts file, then TS will NOT error on this code as it sees the argument type as any.
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.
Activity
jcalz commentedon Oct 15, 2024
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.
davo-canva commentedon Oct 15, 2024
To preempt the question as to why this doesn't use parameter properties, the actual code looks more like this:
bradzacher commentedon Oct 15, 2024
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
anythen 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.MichaelMitchell-at commentedon Jan 16, 2025
I could see this still being a footgun with isolated declarations, since it doesn't seem like the checker could easily issue a semantic error without doing some type analysis.