-
6702 - readonly in .d.ts files
- Problem: typescript@next users can't give their generated .d.ts files to 1.8 users
- What's the difference between this and e.g. union types?
- This one doesn't require any opting-in
- Not universally true -- some expressions became union types, for example
- Options
- Commandline flag
- Tool (regexp or something smarter)
- Don't emit readonly in .d.ts until 2.0 ships, or "later"
- Don't use typescript@next if your consumers aren't either
- Who's encountering this?
- tslint
- Angular
- Are they going to support pre-2.0 customers once 2.0 ships?
- They only care about the window between the prerelease build and the real release
- If we did it "later", how much later?
- We'd like library authors to continue using bleeding-edge (good for us, good for them)
- --sourceVersion or --dtsVersion ?
- Very complex for marginal gain
- Going forward, think about this scenario more explicitly
- Conclusion: Use a regexp
-
8191 - this in object literals
- Breaks patterns people (Yehuda) use
- In Ember.Object.extend, why doesn't init provide a contextual super type?
- Works, but what about Object.assign ?
- Could you even write the extend signature correctly?
- No because you'd either get the base type or your own type, but not the & of them
- 😕
- Options
- Go back to any, flag an error under --noImplicitThis
- extend signature still impossible to write in an inferential way
- Any other feedback on this yet?
- Ryan remembers bugs wanting this but can't find them? Nathan found No referencing/intellisense fo nested properties/functions within class #7801
- Some way for Ember.Object.extend to say to disable this behavior?
- Contextual type with [s: string]: any signature
- Add the object literal type to the contextual type when computing local this
- Conclusion: See if it's possible to do this with contextual type + smarter this computation
-
8124 - Typechecking of dependencies
- Example scenario: You get a bundled .d.ts file written with implicit anys, then try to compile with --noImplicitAny
- Interface reopening means errors might get reported in unexpected places
- Why do we typecheck these at all?
- Not doing it turned out poorly
- We don't have the mechanics to report errors deterministically when not typechecking every file
- Angular's doing it anyway
- This issue is just about file-level suppression
- Rathole on error numbers
- Our behavior in the presence of certain errors is not universally well-defined
- Conclusion: Tactical fixes only
Reactions are currently unavailable
6702 - readonly in .d.ts files
8191 - this in object literals
8124 - Typechecking of dependencies