Repository navigation
perf(engine): typecheck a save over the project's own files only - #191
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Every builder save typechecks the project before it writes. The check asked TypeScript for the whole program's diagnostics. Those include every declaration file in
node_modules, and the builder drops their errors anyway. On the DMS module template (declaration: true, noskipLibCheck) that dropped work was most of each save.The loop walks the program's files, not
project.getSourceFiles(), so a file that only an import reaches is still checked. Examples are a file created in an editor while the server runs, or one outsideinclude.Evidence
Evidence level: benchmark of the engine operations, plus an end-to-end profile in the dashboard.
Workload: the repository playground (Board page, orders table) copied into a fixture inside the package. Each operation is called the way the dashboard calls it, with the draft built the way
structureToDraftbuilds it. Sides run interleaved, 5 runs each of 3 calls, on a shared and noisy server.SetPageBlocks(a dashboard save)ConfigurePageAddBlockSetPageBlocks, 10 pagesThe typecheck alone, measured with the template's tsconfig: 4568 ms (3672–5216) before, 496 ms (390–632) after. The diagnostics are the same with and without a type error, including an error in a file outside
includeand one in a file created after the project was parsed. WithskipLibCheck: truethere is no change: 272 ms before, 248 ms after.Cumulative impact: about 1 s less waiting on each save in the editor, every save. The order of diagnostics across files can change. Only the joined error banner reads that order.
The engine specs (
test:unit) pass: 523 passing.Verification
pnpm run checkspasses. Main failssync:checkon a stale compat row inpackages/dms-builder/README.md(interface-dms-builder 0.4.0, published 0.4.1), so a separate commit syncs it. It is the same line build(deps): move to @antelopejs/tooling-configs 0.5.0 #190 carries, byte for byte, so whichever of the two lands second has an empty or trivial conflict there.smoke,blocks(3),pages(3) andresources(4) journeys pass. Dashboard save, Save click to the server's answer, 15 saves per side: 2325 ms (2010–3792) on main, 630 ms (440–1102) with the three PRs.formal-page-save: the same output on main and on this branch. The only finding is the recorded F2 (Moving a page with an unsaved draft lets the next Save overwrite an outside change without the stale banner #163), which none of these lines touch. The gate flags the covered code's emit as changed.Merge Danger
Door: two-way. Nothing is stored. A revert restores the old check.
Blast Radius: saves.
A diagnostic located in an own file that TypeScript reports only while checking a
node_modulesdeclaration file would no longer refuse a save. Neither review found a checker path that does this.