Skip to content

Design Meeting Notes, 6/3/2022 #49384

Closed
Closed
@DanielRosenwasser

Description

@DanielRosenwasser

Module Transformation/Conversion Update

#49332

  • Switched to ts-morph - much easier to use, does better with comment preservation and the like.
  • Repo produces commits that make each step explicit if you're interested in reading.
  • What are the issues?
    • In order to continue to provide a "namespace" object, we need to create a bunch of export *s.
      • All in a _namespaces directory.
      • Lots of circularities in the codebase though. Can't rely on the namespace versions because they don't enforce appropriate ordering - it just forces the ordering of all the export *s.
      • Switching to explicit imports from each dependency forces a more correct evaluation order (though not necessarily perfect - still some circularities).
  • Also /** @internal */ on an entire module doesn't work.
    • /** @external */ lol
    • Can possibly use /** @internal */ on the export *.
  • Barrel module overhead?
    • There's a layer of indirection.
    • Unclear.
  • Several issues around API diffs.

Forbidding Destructured Property Renaming in Function Types

#41044

// Error under noUnusedParameters.
const foo = ({ x: xRenamed, y }) => {
    return y;
}
  • Okay, value space makes sense.

  • What about type space?

    type Foo = ({ x: xRenamed, y }) => void;
    • EXTREMELY misleading.
      • Useless entirely.
      • Looks like a type annotation.
  • Community PR to disallow this in type annotations.

    • But...
      • In declaration emit, we actually emit the destructuring. We don't have a name.
  • Maybe worth updating this as noUnusedParameters.

    • Could make this an error in non-.d.ts files.
    • Maybe add a good error message for "if you're trying to use this as a type..."
  • Do we need to fix these for .d.ts files? All the "wrong code" on DefinitelyTyped?

    • noImplicitAny will catch these.

Instantiation Expressions with Binary Operators

#49362

  • When we successfully parse out a type argument list, we say "if there's a binary operator, defer".
  • Got brought up when we saw an ASI-encouraged style had issues with instantiation expressions.
  • Started off with saying "if it's ambiguous, a user has to parenthesize" - now we're changing our minds?
  • Much of this may be due to parser complexity.
  • Need to make a call. Want to not diverge, but perhaps picking the JS interpretation is overly pedantic?

Optional Chaining and Instantiation Expressions

#49293

Out of time.

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