test(core): add T6a GSAP parser golden baselines (Recast/Babel snapshot)

[vanceingalls]

Summary

• Adds packages/core/src/parsers/gsapParser.golden.test.ts with 6 toMatchFileSnapshot tests across 3 representative GSAP scripts (minimal/moderate/complex)
• Golden files are checked in at src/parsers/__goldens__/ and capture both parseGsapScript JSON output and serializeGsapAnimations string output under the current Recast/Babel parser
• Time-sensitive: must be merged before the Recast → Meriyah swap (R? branch) so the swap has a regression gate — any parser behavior change will surface as a golden diff rather than a silent behavioral change
• Excludes __goldens__/ from fallow (ignorePatterns) and oxfmt (.prettierignore) since vitest owns formatting of snapshot files

Corpus:

• minimal — 2 tl.to calls, numeric selectors (macos-notification block)
• moderate — 6 tl.to calls, multiple CSS-id selectors (yt-lower-third block)
• complex — stagger, chained .from() calls, const + timeline defaults (vpn-youtube-spot block)

Test plan

• bun run --cwd packages/core test -- gsapParser.golden.test.ts — 6 pass, 0 failures
• bun run --cwd packages/core test -- -u gsapParser.golden.test.ts after any parser change shows diffs in __goldens__/ files

[vanceingalls]

• test(core,studio): add T3+T7 hfId targeting stubs (spec for R1) #1267
• test(core): add T6a GSAP parser golden baselines (Recast/Babel snapshot) #1263 👈 (View in Graphite)
• test(core): add T10 PreviewAdapter contract stubs (spec for R7) #1262
• refactor(core): extract maxEndTime+serialize to parsers/test-utils.ts (TU) #1261
• test(studio): add T5c review-fix gaps in manualEditsDomPatches characterization #1259
• test(studio): add T5b rotation+motion build-patches characterization #1258
• test(studio): add T5a pathOffset+boxSize build-patches characterization #1257
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[miguel-heygen]

Golden baseline approach is correct for a parser that transforms JS source — toMatchFileSnapshot gives diff-friendly failure output on regression, and gating on Recast before the Meriyah swap is the right sequencing.

A few things worth confirming:

Sorted emission order in complex.serialized.js — animations come out sorted by position ascending (0.05, 0.08, 0.16, 0.2), not declaration order. This is captured in the golden but not narrated in a test description. If the sort is an intentional design decision, a comment in gsapParser.golden.test.ts noting it would help a future Meriyah swapper know this is expected, not an artifact.

__raw: prefix convention — stagger values appear as "__raw:0.08" and "__raw:0.055" in the parsed JSON, indicating they're kept as raw JS expressions. The golden captures this correctly. Same note: a brief comment in the test file or the golden would clarify this is by design.

.fallowrc.jsonc and .prettierignore — both updated. Consistent with the repo's pattern for excluding generated files. No issues.

P2 suggestion (not a blocker): the parseAndSerialize helper returns { parsed: string, serialized: string }. If either the parser or serializer throws, the test just fails with an unguarded error rather than a useful "parsed step failed" message. Adding a try/catch with labeled rethrowing would make failures in large corpus inputs much easier to diagnose. Low priority for characterization tests, but worth doing before T6b/c.

Approved — goldens look correct, infrastructure changes are clean.

[james-russo-rames-d-jusso]

Round-1 review of T6a (GSAP parser golden baselines for the Recast → Meriyah swap). +321/-0, 9 files: 6 golden snapshot files (3 scripts × 2 functions), 1 test file, 2 ignore-file updates. Walked the diff with the lens of (1) coverage vs. parser surface, (2) snapshot vs. assertion trade-off, (3) corpus selection, (4) fallow + oxfmt ignoring, (5) the swap-PR-diff-readability claim.

What's strong

Snapshot-baseline shape is the right call here. The PR body argues this explicitly and I agree — the goal is "diff the parser swap against the current behavior" rather than "lock in correctness." Explicit assertions across 3 scripts × parseGsapScript + serializeGsapAnimations would be ~6 huge toEqual blocks and would obscure WHICH fields changed when Meriyah lands. toMatchFileSnapshot produces a reviewable file-level diff that's the actual review artifact for the swap PR.

__goldens__/ excluded from both fallow and oxfmt. Both .fallowrc.jsonc:38-39 and .prettierignore:5-6 updated with the right rationale ("vitest owns formatting"). ✓ Without these, the goldens would get reformatted on commit and the snapshot diffs would become unreadable.

Inline corpus scripts (not registry-coupled). Lines 25-66 define MINIMAL_SCRIPT / MODERATE_SCRIPT / COMPLEX_SCRIPT as const strings rather than reading from the registry. Right call — if a registry script gets updated for unrelated reasons (animation tweak, copy change), the goldens shouldn't churn.

The describe → beforeAll → it × 2 pattern. Each describe block parses once, then asserts parsed and serialized snapshots independently. So if the parser breaks but the serializer is fine (or vice versa), the failure narrows the blast radius automatically. Tighter than running both assertions in one it.

Concerns

[important — corpus undercount vs. parser support surface] gsapParser.ts:41:

const GSAP_METHODS = new Set<string>(["set", "to", "from", "fromTo"]);

The parser supports four methods. The corpus exercises only tl.to and tl.from — gsap.set and tl.fromTo are unrepresented. So the Meriyah swap could subtly break tl.fromTo parsing or gsap.set capture, and the goldens won't catch it.

Additionally, looking at the parser's scope-binding + literal-resolution machinery (gsapParser.ts:57-115), there are several shapes the swap could affect that the corpus doesn't exercise:

• tl.fromTo(target, fromVars, toVars, position) — distinct three-object signature. Different node shape, different traversal in the AST visitor.
• gsap.set(target, vars) at module scope. Looking at MINIMAL_SCRIPT line 30 (gsap.set(notification, ...)) — the golden output for minimal shows only the 2 tl.to animations, no gsap.set. So the parser filters out gsap.set calls. The "set" branch (GSAP_METHODS.has("set")) is reachable but apparently no-op. Worth either documenting in the test why set isn't visible in the golden, or adding a corpus script that does surface a gsap.set-derived animation if there's a code path that should.
• Math.ceil(7 / 2.4) - 1 in COMPLEX_SCRIPT:51 — but breatheRepeats is never used. The scope-binding resolution at resolveNode:90-105 handles BinaryExpression with arithmetic operators; if Meriyah changes how arithmetic literals fold, this would silently drift. Unfortunately breatheRepeats doesn't reach a tl.* call so the corpus doesn't exercise the binding lookup at all. Worth either using breatheRepeats in a tl.repeat() or similar, or dropping it from the script as dead.
• Negative numbers / UnaryExpression with - operator. The parser handles -5 at resolveNode:88-91. No corpus script has negative property values or positions.
• Template literals (UnaryExpression arm at line 112). No corpus script uses backticks.
• Labels (tl.addLabel("start") + tl.to(…, "start")) or callback adds (tl.add(() => {…}, 1.0)). If the parser handles these — and given the AST visitor's breadth I'd guess it tries — they're a high-risk path under a parser swap. (If it explicitly doesn't handle them, that's worth a negative test too.)

Not all of these need new corpus scripts. Three additions I'd specifically suggest:

1. Add a fromTo corpus script — any meaningful coverage of the third parser method.
2. Either use breatheRepeats to feed a tl.repeat or drop it; otherwise the AST-binding paths through resolveNode aren't covered.
3. Add at least one negative number (e.g. { y: -46 }) somewhere — the UnaryExpression arm is unrepresented.

The fourth method (set) is parsed-but-filtered behavior; a comment in the test explaining why goldens don't show gsap.set outputs would close that loop.

[concern — snapshot ratcheting risk on parser-touching PRs] The Meriyah swap is the intended golden diff. But this baseline now also captures behavior for every other PR that touches gsapParser.ts or gsapSerialize.ts between now and then. A contributor who lands an incidental parser tweak and regenerates goldens with --update-snapshots makes the change invisible in the next reviewer's eye.

Mitigation: a .github/CODEOWNERS rule on packages/core/src/parsers/__goldens__/** requiring an extra reviewer on golden updates, or a CONTRIBUTING.md note saying "if you touch a __goldens__ file, justify the regenerated diff in the PR body." Not blocking — discipline-by-convention works fine for a small team — but worth a one-line note somewhere.

[nit — trailing-no-newline on golden files] The \ No newline at end of file markers on each golden output (e.g. minimal.serialized.js:6 has no trailing \n). This is whatever parseGsapScript + JSON.stringify produce — vitest captures the bytes literally. Not a bug, but the inconsistency between "has trailing whitespace" and "no trailing newline" can confuse editors that auto-add \n on save. Worth a .gitattributes entry like packages/**/__goldens__/** -text to disable line-ending normalization on these files, or just be aware that someone editing a golden by accident will get a noise diff.

Nits

• g = (name: string) => join(__goldens__, name) (line 21) is a one-call helper used 6x — fine, but if the corpus grows past one parser module, consider just inlining join(__goldens__, "minimal.parsed.json") for readability.
• beforeAll(() => { ({ parsed, serialized } = parseAndSerialize(MINIMAL_SCRIPT)); }) — could be beforeAll(() => Object.assign(this, parseAndSerialize(…))) if you wanted to avoid the destructuring assign pattern, but the current shape is fine.

Plan-doc alignment

T6a = "Recast/Babel snapshot baseline before parser swap." Scope matches. The follow-up R-branch is the Meriyah swap which expects this golden to be present as a regression gate.

Verdict

Right shape for the goal. The corpus-coverage gap (4 supported methods, 2 exercised) is the only concern worth surfacing as something to address before this lands as the swap-PR's regression gate — even one additional fromTo corpus script materially tightens the safety net. Leaving as a comment.

— Review by Rames D Jusso

The base branch was changed.