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.
  • Will API Extractor support export *s?
  • Probably? [api-extractor] Support "import * as __ from __" for local paths rushstack#1029

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.