Closed
Description
-
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?
- No
- They only care about the window between the prerelease build and the real release
- Are they going to support pre-2.0 customers once 2.0 ships?
- 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
- Problem:
-
8191 -
this
in object literals- Breaks patterns people (Yehuda) use
- In
Ember.Object.extend
, why doesn'tinit
provide a contextualsuper
type?- Works, but what about
Object.assign
?- Well you're screwed
- 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
- Works, but what about
- 😕
- 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?
- Nope
- 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
- Contextual type with
- Add the object literal type to the contextual type when computing local
this
- Go back to
- 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
any
s, 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
- What are the scenarios?
- Rathole on error numbers
- Our behavior in the presence of certain errors is not universally well-defined
- Conclusion: Tactical fixes only
- Example scenario: You get a bundled .d.ts file written with implicit