Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Meeting Notes, 6/3/2022 #49384

Closed
DanielRosenwasser opened this issue Jun 3, 2022 · 0 comments
Closed

Design Meeting Notes, 6/3/2022 #49384

DanielRosenwasser opened this issue Jun 3, 2022 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

2 participants