Description

Ryan Cavanaugh (RyanCavanaugh)

opened on Apr 22, 2016

Issue body actions

• 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
  • 😕
  • 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
    • 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
    • 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

Activity

1. Ryan Cavanaugh (RyanCavanaugh)

   added

   Design NotesNotes from our design meetingsNotes from our design meetings

   on Apr 22, 2016
2. DanielRosenwasser commented on Apr 22, 2016

   

   Daniel Rosenwasser (DanielRosenwasser)

   on Apr 22, 2016

   Member

   More actions

   Could you contextually type the argument to extend like so?

   interface BoundMethod<T> {
       (this: T, ...args: any[]): any;
   }
   
   interface ObjectWithBoundMethods<T> {
       [propName: string]: BoundMethod<T> | {}
   }
   
   class MyObject {
       extend<T extends ObjectWithBoundMethods<T & this>>(other: T): T & this;
   }
3. Ryan Cavanaugh (RyanCavanaugh)

   closed this as completedon Apr 22, 2016
4. microsoft

   locked and limited conversation to collaborators on Jun 19, 2018

Issue actions