Review comments on #57934 are mostly concerned with --build usage - as an internal option that errors on the CLI/in a config, it can't currently be used with --build without reaching at nonpublic API internals, which also make it difficult to test in a realistic way. That PR adds some psuedo-build tests that baseline current behavior (along the lines of "how will this work once actually exposed"), but current usage is definitely at-your-own-risk (we may even still rename it before it's exposed 😆) - hopefully that's evident by it being @internal. Specifically, @sheetalkamat has expressed concerns that forcibly running a noCheck build via the API (again, nonpublic, unsupported) and then a normal build on the CLI with --build may not work correctly (in that it may not calculate new diagnostics, since outputs are newer than inputs, and the CLI is unaware the last build was run with differing options). This issue with --build on the CLI and other non---build builds (without --incremental) isn't terribly --noCheck specific, and isn't something you should do - but you may be tempted to do because --noCheck is so useful. Just... don't? Wait for us, please. Our @internals are @internal for a reason. 😅
In the future PR where we make it CLI-accessible (after we enable it for JS emit), we should:
Ensure it has an appropriate level of .buildinfo invalidation (which should just be the usual tscWatch style tests and accompanying option description fields, probably, though maybe further optimizations are available).
Additionally, we should:
Make changes to --build as a whole to allow semantic-affecting diagnostics like --noCheck globally in a project - this is a fairly independent fix, but has much more value with flags like --noCheck that meaningfully change the compiler's performance profile, and seems to require always emitting a .buildinfo for a build, even when it's not incremental, so we at least know the options that last build was made with and if changes to them cause more invalidation than the timestamps otherwise imply. Hopefully our solution here also applies to any API-made builds (in that they should probably also make a .buildinfo), at least through appropriate API layers (we have many). I don't know if this should be a prerequisite to public CLI --noCheck, but it would certainly be nice to have, and many usecases for --noCheck would be unlocked (or made less footgun-y) by this fix.
Those two parts (exposing --noCheck publicly on the CLI and changing --build to invalidate based on options in .buildinfo even when --incremental is false) are likely independent units of future work without a hard dependency on one another, but both are what you want to see to call this issue complete.
Review comments on #57934 are mostly concerned with
--buildusage - as an internal option that errors on the CLI/in a config, it can't currently be used with--buildwithout reaching at nonpublic API internals, which also make it difficult to test in a realistic way. That PR adds some psuedo-build tests that baseline current behavior (along the lines of "how will this work once actually exposed"), but current usage is definitely at-your-own-risk (we may even still rename it before it's exposed 😆) - hopefully that's evident by it being@internal. Specifically, @sheetalkamat has expressed concerns that forcibly running anoCheckbuild via the API (again, nonpublic, unsupported) and then a normal build on the CLI with--buildmay not work correctly (in that it may not calculate new diagnostics, since outputs are newer than inputs, and the CLI is unaware the last build was run with differing options). This issue with--buildon the CLI and other non---buildbuilds (without--incremental) isn't terribly--noCheckspecific, and isn't something you should do - but you may be tempted to do because--noCheckis so useful. Just... don't? Wait for us, please. Our@internals are@internalfor a reason. 😅In the future PR where we make it CLI-accessible (after we enable it for JS emit), we should:
.buildinfoinvalidation (which should just be the usualtscWatchstyle tests and accompanying option description fields, probably, though maybe further optimizations are available).Additionally, we should:
--buildas a whole to allow semantic-affecting diagnostics like--noCheckglobally in a project - this is a fairly independent fix, but has much more value with flags like--noCheckthat meaningfully change the compiler's performance profile, and seems to require always emitting a.buildinfofor a build, even when it's not incremental, so we at least know the options that last build was made with and if changes to them cause more invalidation than the timestamps otherwise imply. Hopefully our solution here also applies to any API-made builds (in that they should probably also make a.buildinfo), at least through appropriate API layers (we have many). I don't know if this should be a prerequisite to public CLI--noCheck, but it would certainly be nice to have, and many usecases for--noCheckwould be unlocked (or made less footgun-y) by this fix.Those two parts (exposing
--noCheckpublicly on the CLI and changing--buildto invalidate based on options in.buildinfoeven when--incrementalisfalse) are likely independent units of future work without a hard dependency on one another, but both are what you want to see to call this issue complete.