fix(compiler): include compiler version in persistent cache fingerprint - #754
Closed
clayrisser wants to merge 1 commit into
Closed
fix(compiler): include compiler version in persistent cache fingerprint#754clayrisser wants to merge 1 commit into
clayrisser wants to merge 1 commit into
Conversation
The transform cache in node_modules/.vxrn/compiler-cache validates entries
against input file mtime/content and a fingerprint of the config toggles
only. Transform output also depends on the compiler implementation itself,
so entries written by an older @vxrn/compiler survive an upgrade (inputs
and config unchanged) and keep serving stale transforms.
Fold the compiler's own package version into getConfigFingerprint() so the
cache invalidates whenever the compiler changes. Version discovery mirrors
getPackageVersion() in packages/one/src/cli.ts (CJS/ESM dual dirname, works
from dist/{esm,cjs} and from src for tests), with a static fallback marker
if package.json cannot be found.
Co-authored-by: Cursor <cursoragent@cursor.com>
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
1 participant
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.
Symptom
After changing
@vxrn/compiler's transform behavior (upgrading it, or in our case editing a carried pnpm patch on it), dev builds kept serving the old transform output. The persistent transform cache innode_modules/.vxrn/compiler-cachelives in the app'snode_modulesand survives package upgrades, so stale entries keep winning until someone manually deletes the cache dir — a very confusing failure mode, because the symptom looks like "my compiler change did nothing."Root cause
getCachedTransform()validates entries against input file mtime + content hash, plusgetConfigFingerprint()— which hashes only the four config toggles (enableCompiler,enableReanimated,enableNativewind,enableNativeCSS):Nothing in the cache key captures the compiler implementation itself, so any release that changes transform output (or any patch applied to the package) silently reuses transforms produced by the previous implementation.
Fix
Fold the compiler's own package version into
getConfigFingerprint(). Version discovery mirrors the existinggetPackageVersion()pattern inpackages/one/src/cli.ts(CJS/ESM dual__dirname/import.meta.urlhandling); it walks..and../..so it resolves the rightpackage.jsonboth from compileddist/{esm,cjs}output and straight fromsrc(tests), verifiesname === '@vxrn/compiler', and falls back to a static marker if the read fails.Verification
Smoke-tested against the public cache API (
setCachedTransform/getCachedTransform) with a fixed input file and default config, comparingmainvs this branch:mainwrites cache keyc9fc91f1…(no version in the fingerprint)91a459dd…, which exactly matches an independently recomputed sha1 of the fingerprint JSON withversion: "1.24.1"— proving the version resolves for real (not the fallback) and lands in the keytsc --noEmit,oxlint, andoxfmt --checkare clean on the package. (vitest run --dir srccurrently fails on unmodifiedmainin my environment with aviteresolution error fromtransformBabel.test.ts, unrelated to this change.)Downstream
We hit this in production in the multiplatform.one framework, where we carry pnpm patches on
@vxrn/compiler(Hermes dev-lowering fixes we're upstreaming separately): after every patch edit the compiler cache kept serving pre-patch transforms. We currently carry a manualPATCH_VERSIONmarker in the fingerprint as a pnpm patch; a version-based marker upstream retires it and fixes the general upgrade case for everyone.Made with Cursor