docs(skills): fix anime.js v3 syntax in v4 adapter guidance - #3064
Open
youngeuibae wants to merge 1 commit into
Open
docs(skills): fix anime.js v3 syntax in v4 adapter guidance#3064youngeuibae wants to merge 1 commit into
youngeuibae wants to merge 1 commit into
Conversation
The animejs adapter docs teach v3 syntax against a v4 build, so the examples
cannot run as written: every v4 bundle assigns a *namespace object* to the
global `anime`, making v3's `anime({ targets })` call form a TypeError. `easing:`
is now `ease:`, ease names lost their `ease` prefix, and `timeline.add()` takes
`(targets, parameters, position)`.
- Rewrite `skills/hyperframes-animation/adapters/animejs.md` for v4:
`anime.animate()` / `anime.createTimeline()`, `ease:` names, targets-first
`add()`, position shorthands, and a note that the producer fixtures pin
4.0.2 (`lib/`) while 4.1+ moved bundles to `dist/bundles/`.
- Fix the same v3 `anime.timeline({ targets })` snippet in
`skills/hyperframes-keyframes/references/keyframe-patterns.md`.
- Stop advertising `anime.running` auto-discovery as a safety net. No v4 build
exports `running` (checked 4.0.2 and 4.5.0), so `discover()` returns
immediately and any instance a composition forgets to push onto
`window.__hfAnime` is silently never seeked. Marked v3-only/inert in the
skill page and the adapter docstring; explicit registration is now stated
as mandatory.
- Add render-safety notes the page lacked: `createSeededRandom()` as the
deterministic replacement for `Math.random()`, and why
`autoplay: onScroll(...)`, `createDraggable`, and pointer-driven
`createAnimatable` cannot work under headless seek rendering.
- Regenerate skills-manifest.json.
Runtime behaviour is unchanged: the `packages/core` edit is comment-only, and
the seek path already works on v4 (registered instances expose
seek/pause/play). The now-dead `anime.running` branch in `discover()` is left
in place — it is guarded and try/caught, and removing it is a behaviour change
that belongs in its own PR.
youngeuibae
force-pushed
the
fix/animejs-v4-adapter-docs
branch
from
August 6, 2026 08:24
a3b4689 to
3e98e2b
Compare
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.
Problem
skills/hyperframes-animation/adapters/animejs.mddocuments anime.js v3 syntax while telling compositions to load a v4 build, so the examples on the page cannot run as written:Every v4 bundle — UMD and IIFE alike — assigns a namespace object to the global
anime(var anime = (function (t) { … return t })({})), so v3's call form is aTypeErrorno matter which v4 file is loaded. On top of thateasing:is nowease:, the ease names lost theireaseprefix (easeOutExpo→outExpo), andtimeline.add()takes(targets, parameters, position).The same v3 snippet appears in
skills/hyperframes-keyframes/references/keyframe-patterns.md(anime.timeline({ … })+add({ targets })).The one that fails silently
Both the skill page and the adapter docstring advertise
anime.runningauto-discovery as a safety net for "compositions that forget to register manually". No v4 build exportsrunning— I checked the published4.0.2(the version the repo's own fixtures pin) and4.5.0. Sodiscover()hits itstypeof running === "undefined"guard and returns immediately. An unregistered instance is simply never seeked: no error, no warning, just a frozen element in the render.Changes
skills/hyperframes-animation/adapters/animejs.md— rewritten for v4: the namespace-vs-callable distinction,anime.animate()/anime.createTimeline(),ease:names, targets-firstadd(), position shorthands (<,<<,+=).skills/hyperframes-keyframes/references/keyframe-patterns.md— same v3 snippet, corrected.window.__hfAnime.push(...)is now stated as mandatory rather than optional.createSeededRandom()as the deterministic replacement forMath.random()(the determinism rules forbid the latter but named no alternative), plus whyautoplay: onScroll(...),createDraggable, and pointer-drivencreateAnimatablecannot work under headless seek rendering.skills-manifest.jsonregenerated (hyperframes-animation,hyperframes-keyframes).A version note, not a version bump
The examples target 4.5.0 (
dist/bundles/anime.umd.min.js), becausesplitText/scrambleText/createSeededRandom/createLayout— cited on the page — do not exist in 4.0.2. The page says so explicitly rather than silently implying the fixtures are wrong:animejs@4.0.2/lib/anime.iife.min.jsstill resolves, and 4.1+ moved the bundles todist/bundles/, so bumping the pin requires changing the path too. I left the fixtures underpackages/producer/tests/animejs-adapter/andpackages/producer/tests/distributed/anime-boundary/alone — they use the same v3 call form and would need their recorded output regenerated, which felt like a separate change to hand you rather than fold in here.Runtime behaviour is unchanged
The
packages/coreedit is comment-only — no logic touched. The seek path already works on v4 (registered instances exposeseek/pause/play). I deliberately leftdiscover()'s now-deadanime.runningbranch in place: it is guarded and try/caught, so it is harmless, and removing it is a behaviour change that deserves its own PR if you want it.One item is marked unverified on the page rather than asserted: whether
waapi.animate()-backed instances honour.seek(). The page steers rendered compositions to the JS engine instead of guessing.Verification
Run on this exact base (
88853f17):lefthookpre-commit checks pass:tracked-artifacts,lint,format,typecheck,skills-manifest,largefiles,fallow— pluscommitlint.bunx tsc --noEmitclean inpackages/coreandpackages/studio.vitest run src/runtime/adapters/animejs.test.ts→ 15/15 pass.Full-monorepo
bun run testdoes not complete on my machine (Windows / Node 24): vitest'stinypoolworkers die withERR_IPC_CHANNEL_CLOSEDduring teardown, which reproduces in packages I did not touch (e.g.packages/parsersreports 2 failed test files with 0 failed tests, 721 passing). CI will be the real check there.