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
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 for transpileModule that would be a big win.
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 the import condition, now resolves with the require condition.
Kind of weird under --preserve, but 🤷♂️.
Under --module preserve, we issue something like verbatimModuleSyntax errors because it won't be interpreted the same way from a declaration file.
Did not add logic to disallow CommonJS input files. Presumably a program-level error if we wanted to add it.
The text was updated successfully, but these errors were encountered:
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?
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?
Aside: do we need symbol baselines?
tsc --noCheck
#57934
--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).--noCheck
, but if we can unlock this fortranspileModule
that would be a big win.skipCheck
?noCheck
to parallelnoEmit
?Respect
type
inpackage.json
in moremodule
modes#57896
.cjs
module under--module esnext
got emitted with ES syntax; no longer does..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.--preserve
, but 🤷♂️.--module preserve
, we issue something likeverbatimModuleSyntax
errors because it won't be interpreted the same way from a declaration file.The text was updated successfully, but these errors were encountered: