- # 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 - 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` ? - 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 - :confused: - 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 #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 `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