You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Gist of the PR is that when you have an as assertion, like const x = foo as number, you should be able to do declaration emit as const x: number = foo.
Valid to move between a top-level type in an as versus an annotation.
Last time we discussed, we liked this because it reused more nodes, but concerns were raised that this logic should live in the TypeChecker versus the EmitResolver.
TypeChecker and its NodeBuilders takes care of many of the concerns.
If we want to scale out builds, relying on the TypeChecker for this causes problems.
But if we actually care about perf, why are we not committing to a fast transpileDeclaration?
Current feedback we've provided is just to stick to checks and make our output conform more with an isolated declaration emitter.
A faster implementation can happen down the line.
Or an alternative emit resolver can do the logic in the PR instead of calling out to the checker.
Also: doing this in the checker means that JS declaration emit gets better.
A lot of PRs for a large change - asking to reorganize this has a lot of back-and-forth and risks slipping on 5.4.
Conclusion: we will prototype a change where this work is done in the NodeBuilder.
Do not preserve triple-slash references unless marked preserve
Reusing Type Nodes from Assertion Expressions
#57587
#57589
as
assertion, likeconst x = foo as number
, you should be able to do declaration emit asconst x: number = foo
.as
versus an annotation.TypeChecker
versus theEmitResolver
.TypeChecker
and itsNodeBuilder
s takes care of many of the concerns.TypeChecker
for this causes problems.transpileDeclaration
?NodeBuilder
.Do not preserve triple-slash references unless marked
preserve
#57655
#57681
preserve
.isolatedDeclarations
going to be compatible with--module amd/umd
?isolatedModules
is incompatible with--outFile
, which those work with.preserve
is not the worst workaround.Spec conformance (break) on decorator syntax in
--experimentalDecorators
#57749
We have a fairly lax sytnax
Decorators proposal says either parenthesized expressions or dotted names with a trailing call expression.
TypeScript's decorator implementation is much more relaxed on the grammar though. So we should decide on how we take the break.
experimentalDecorators
?Current implementation still parses gracefully and emits well.
Most people feel like we want a consistent grammar error between the two.
Have a quick fix to just parenthesizes.
Top repos?
We do allow postfix
!
because it's TypeScript only.Type argument instantiation expression?
Conclusion: ship it.
Do not emit reverse mappings for syntactically deteriminable strings
#57686
Today when we see an enum like
under
transpileModule
, we create a reverse-mapping for it(!)/We need to choose what we want to happen.
isolatedModules
, orProposal: when we see see certain initializers, don't create the reverse mapping entry.
What happens if you don't have it in a template string?
We do create a reverse-mapping there, but it errors in
isolatedModules
.The text was updated successfully, but these errors were encountered: