Open
Description
Format Types Consistently in Baselines and Underlining Type Node Generation
-
Apply same single-line style to copied nodes as manufactured ones #57890
-
Underline type nodes without position mappings in .types baselines weswigham/TypeScript#69
-
As we try to maximize node reuse, we realized we have no indication as to whether that is taking place apart from whitespace as a heuristic.
-
Even then, preserving whitespace isn't always desirable.
-
This PR adjusts type baselines to always apply the same formatting consistently.
-
A separate PR adds an underline to indicate when a node was synthesized.
-
What are we trying to catch here?
- Lack of node reuse.
- Could exhaustively check things, but better off using our current infrastructure.
-
Kind of a pain to read these.
-
Is it arguable that the underlines actually indicate that you should pay attention even if you only care about the types?
- Maybe.
-
Aside: do we need symbol baselines?
tsc --noCheck
- For TypeScript? Isn't that weird??
- Idea: allows people to perform a check and a build separately.
- Declaration emit actually surprisingly works here. Most of the information can be calculated lazily, and so it avoids a full check.
- Unfortunately, JavaScript emit actually calculates some information in the checker.
- This is very surprisingly fast.
- The only downside of using
--noCheck
for declaration emit is that it may differ in output from stuff like union ordering (which depends on types being assigned IDs, which is sensitive to check order). - Our main goal is to be a type-checker.
- How does this work with syntax errors?
- You won't get them.
- Unclear if it's a good idea to bring this in without making this possible for the JS side. We need to try decoupling JS emit to see what if anything regresses.
- Mixture of support for the concept of
--noCheck
, but if we can unlock this fortranspileModule
that would be a big win. - Don't want to add a command line flag just yet.
- Bike-shed a name.
skipCheck
?noCheck
to parallelnoEmit
?
Respect type
in package.json
in more module
modes
- Some notable changes:
- A
.cjs
module under--module esnext
got emitted with ES syntax; no longer does. - People using
.cts
files under--moduleResolution bundler --module esnext
(aside: nowadays--module preserve
is what most of these people want), we would resolve with theimport
condition, now resolves with therequire
condition.- Kind of weird under
--preserve
, but 🤷♂️.
- Kind of weird under
- Under
--module preserve
, we issue something likeverbatimModuleSyntax
errors because it won't be interpreted the same way from a declaration file.
- A
- Did not add logic to disallow CommonJS input files. Presumably a program-level error if we wanted to add it.