Repository navigation
Using types from private class properties results in any types in .d.ts filesΒ #60230
Description
Activity
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 ananythen 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.Reacted by David Vo, Jake Bailey, Fabio Spampinato, Mateusz BurzyΕski, Eric Wang, Rob Palmer, Marcelo Camargo, Ryan Cavanaugh and Matt MoranI 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.
π 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.tsis:π Expected behavior
Generated
.d.tsis:Additional information about the issue
This behaviour is problematic because it creates a desync between consumers of
.tsfiles and consumers of.d.tsfiles for the same code.For example:
If the
Footype comes from the.tsfile, then TS will error on this code as it can see that the argument type isstring.OTOH if the
Footype comes from the.d.tsfile, 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
masterbranch (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.tsduring our CLI builds, but (A) consume's (B)'s.tswithin 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.