-
chore: release v0.3.0 (#249)
发布于
2026-04-13 23:16:06 +00:00 Summary
Coordinated minor bump across all published packages. No source changes in this PR itself; it is the version stamp for everything that landed on main since v0.2.5.
Version bumps
Package from to @hyperframes/cli0.2.5 0.3.0 @hyperframes/core0.2.5 0.3.0 @hyperframes/engine0.2.5 0.3.0 @hyperframes/player0.2.7 0.3.0 @hyperframes/producer0.2.5 0.3.0 @hyperframes/studio0.2.9 0.3.0 Between 0.2.5 and this release,
playerandstudioreceived several patch versions on npm as we iterated on the bundler, entry point, and SSR issues. 0.3.0 collapses that into a single coordinated minor so the ecosystem is aligned again.What is in v0.3.0
@hyperframes/playerRestored package entry points to the compiled
dist/output. 0.2.5 shipped with"main": "./src/hyperframes-player.ts"but the published tarball only includeddist/via the"files"field. Every consumer trying to import the package failed withModule not found: Can't resolve '@hyperframes/player'. Entry points now point at the built JS/.d.tsfiles insidedist/.DOM-based root timeline resolution in the ready probe. In a bundled preview,
window.__timelinescontains the master composition alongside its sub-compositions, for example:{ main: GSAPTimeline(14s), intro: GSAPTimeline(1.5s), 'scene2-4-canvas': GSAPTimeline(12.6s), 'scene5-logo-outro': GSAPTimeline(3.2s), }The probe used to select the adapter with
keys[keys.length - 1]. Object key ordering meant the last-registered sub-composition would win, so thereadyevent reported a sub-composition's duration (e.g. 3.2s) instead of the master's 14s. The probe now looks up the root composition id from the outermost[data-composition-id]element in the iframe DOM and uses its key. Falls back to the last key when no element is present, so standalone sub-composition previews keep working.@hyperframes/studiouseTimelinePlayer.getAdapter()uses the same DOM-based root id lookup as the player. Previously play, pause, seek, and duration readout were all driven by whichever sub-composition happened to register its timeline last.Player.tsxloads@hyperframes/playerlazily. The component used to callimport "@hyperframes/player"at module scope, which runs the package'scustomElements.define(...)side effect during module evaluation.HTMLElementdoes not exist in the Node runtime, so any consumer page that transitively imported the studio during server rendering threw:ReferenceError: HTMLElement is not defined at module evaluation (@hyperframes/studio/src/player/components/Player.tsx)The import now runs inside the mount effect via
import(...)so it only evaluates in the browser. Added a cancellation flag and deferred cleanup so a fast unmount before the dynamic import resolves does not leak listeners or DOM nodes.Captions module imports stripped of
.jsextensions. Files undersrc/captions/imported siblings as./types.jsand./parser.js. That is legal ESM TypeScript but Turbopack and several other bundlers refuse to resolve those specifiers against.tsfiles insidenode_modules, breaking any consumer build that transitively pulled in the captions module. Captions now uses extensionless imports, matching the rest of the studio codebase.@hyperframes/core,@hyperframes/cli,@hyperframes/engine,@hyperframes/producerVersion bump only, no source changes since 0.2.5. Kept on the same version so the ecosystem is easier to reason about.
Impact for consumers
If you use
@hyperframes/studioin a Next.js app:- The play button in a bundled preview reports the correct composition duration and drives the master timeline.
- The session page no longer 500s in dev mode when the studio barrel is imported (the SSR fix).
- Turbopack builds that transitively load the captions module no longer fail on
Cannot resolve './types.js'.
If you use
@hyperframes/playerdirectly:- Consumer bundlers can resolve the package again (dist entry points restored).
- The
readyevent duration reports the master, not a sub-composition.
After merge
Publish each package to npm with
pnpm publish(workspace deps auto-resolve).下载附件