Repository navigation
Conversation
… after its build Fixes TanStack#8794 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: 67db0df The changes in this PR will be included in the next version bump. This PR includes changesets to release 5 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
In build mode,
startCompilerPluginonly drops an environment's compiler in that same environment'sbuildStart. Earlier environments' compilers (a module cache full of Babel ASTs, plus closures over the plugin hook context) therefore stay alive while later environments build. On a large app that is about 1.2 GB.Fix
Add a
buildEndhook to the per-environment server-fn plugin. Whenthis.environment.mode === 'build', it deletes that environment's compiler, matching the existingbuildStartcondition. Nothing reads an environment's compiler after its build ends:serverFnsByIdregistry lives outside the compiler.compilers.getis otherwise only used in dev paths (hotUpdate,watchChange, the serve-only lookup plugin).devmode, so its compiler is kept forwatchChange.Testing
tests/vite/start-compiler-plugin-build.test.ts. It drives the plugin'sbuildStart,transformandbuildEndhooks for a build environment, then asserts through aWeakRefand forced GC that the hook context is released. It fails before the fix and passes after.@tanstack/start-plugin-core:test:unit(873 passed),test:typesandtest:eslintall pass.Fixes #8794
🤖 Generated with Claude Code
Summary by CodeRabbit