Skip to content

Design Meeting Notes, 9/13/2019 #33422

Closed
Closed

Description

Private Fields in .d.ts Files

#30829

  • One issue is that .d.ts files are sometimes lossy because private fields omit their types.
    • We probe the structure
  • The variance issue sounds like something we're not likely to address.
    • It's broken today for private, why change for #?
  • Perhaps it makes sense to just include a single #_ declaration in the output if we're just erasing all details.
    • Why don't we just include the original privates in the class declarations?
      • Because you don't want 30 privates in your classes?
      • But that's the case for private properties today.
    • Do private fields affect incremental and project references?
      • Yes, but they probably shouldn't.
      • A point in favor of emitting a single private property?
  • So #_?
    • #privateProperty just so people can search it online more easily.

Collisions of Imported Types

#31231

  • Introducing an error when types conflict with local type names.
import { foo } from "./stuff";
export type foo = foo;
  • Breaks legitimate errors in firebase-firestore, glimmer, skype, vscode.
    • VS Code examples seemed suspicious.
  • The general pattern is useful when running with isolatedModules, but there's no reason to use the same name.
  • This is a breaking change, but the break seems legitimate, existing code seems wrong, and the fix is simple.

Ryan Cavanaugh (@RyanCavanaugh) has the other notes.

Activity

  1. mheiber commented on Sep 16, 2019

    @mheiber
    Contributor

    We implemented the proposed solution for private identifiers in .d.ts files using #private (bikeshedding of the name welcome). Explanation here. Thanks for your time and for the discussion!

  2. RyanCavanaugh commented on Sep 16, 2019

    @RyanCavanaugh
    Member
    • Class fields (private and otherwise)
      • Handle breaking change in class property runtime behavior #27644 Define vs Set
      • What do we do with type-only declarations of properties?
        • This is a problem regardless of Set vs Define
      • Need to make this.p = e in JS files not be treated like field declarations for the purposes of detecting these problems
      • Potential DT Breaks: skatejs, bookshelf
      • PR needs to not do checks against interface properties
      • In 3.7: Emit getters and setters in class .d.ts
      • When do we issue these errors?
        • Only when Define semantics are present?
          • What if you're using Babel to downlevel?
        • Is this a strict mode flag?
      • New flag that is off by default at first, then on
      • Emit
        • Do we need bidirectional flexibility here? Ugh
        • Do we need a way to declare a set-semantics field?
      • x; which means "set to undefined" in proposal
        • We need syntax to say "but don't initialize this"
          • declare x; is the logical choice
  3. Jessidhia commented on Oct 5, 2019

    @Jessidhia

    What if you're using Babel to downlevel?

    That'll depend on your Babel settings as well. Babel (7) will use Define by default, but if you pass the loose: true option to the transform it will use Set.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Design NotesNotes from our design meetings

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions