Closed
Description
Module Transformation/Conversion Update
- 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
import
s from each dependency forces a more correct evaluation order (though not necessarily perfect - still some circularities).
- All in a
- In order to continue to provide a "namespace" object, we need to create a bunch of
- Also
/** @internal */
on an entire module doesn't work./** @external */
lol- Can possibly use
/** @internal */
on theexport *
.
- 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
- Will API Extractor support
Forbidding Destructured Property Renaming in Function Types
// 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.
- EXTREMELY misleading.
-
Community PR to disallow this in type annotations.
- But...
- In declaration emit, we actually emit the destructuring. We don't have a name.
- But...
-
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..."
- Could make this an error in non-
-
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
- 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
Out of time.