Repository navigation
Onboard the lib task to code generation caching and include it in generate - #64409
Wesley Wigham (weswigham) wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
The process-wide fingerprint cache prevents build:watch from detecting edits to existing library files.
Get a fresh assessment by requesting another Copilot review.
Review effort: Balanced
Findings: 1
Open (1)
What changed in this PR
Adds cached library declaration copying to the broader code-generation workflow.
Changes:
- Adds
GeneratedDirectorycaching with tests. - Introduces
generate:libsand includes it ingenerate. - Documents the new task.
| File | Description |
|---|---|
tools/scripts/gen/generatedFile.test.mts |
Tests directory-output caching. |
tools/scripts/gen/generatedFile.mts |
Implements GeneratedDirectory. |
Herebyfile.mjs |
Adds cached library generation tasks. |
CONTRIBUTING.md |
Documents library generation. |
💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
|
I'm surprised this is needed, isn't it just a copy? What diffs do you mean? |
Yeah, though it also needed to delete lib files no-longer-present, which is a bug I've fixed here (we did remove a lib file once in the past).
I was thinking the target libs were still in |
|
There's no such difference anymore; what we ship is what's in the repo, no code generation at all besides copying it in from the DOM lib generator. So the only real step is copying it to It doesn't feel like codegen to me, because every other generator makes thigs we commit? |
|
Alright, we can just leave it as-is, not like it saves any real amount time to make a basic copy option incremental anyway. |

Noticed this was done by watch/build, but not part of the broader codegen task (meaning diffs caused by it could get missed by the
generateCI task). It's basically just a copy action, but codegen is codegen.