chore: release v0.3.0 - #249
Merged
Merged
Conversation
Coordinated minor bump across all published packages. - @hyperframes/cli 0.2.5 → 0.3.0 - @hyperframes/core 0.2.5 → 0.3.0 - @hyperframes/engine 0.2.5 → 0.3.0 - @hyperframes/player 0.2.7 → 0.3.0 - @hyperframes/producer 0.2.5 → 0.3.0 - @hyperframes/studio 0.2.9 → 0.3.0 Cuts a single versioned line under studio + player fixes that landed in #247 and #248 (root timeline DOM resolution, SSR-safe player load, and captions-internal import cleanup).
jrusso1020
approved these changes
Apr 13, 2026
dahans-msft2
pushed a commit
to dahans-msft2/hyperframes
that referenced
this pull request
Aug 6, 2026
## 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/cli` | 0.2.5 | **0.3.0** |
| `@hyperframes/core` | 0.2.5 | **0.3.0** |
| `@hyperframes/engine` | 0.2.5 | **0.3.0** |
| `@hyperframes/player` | 0.2.7 | **0.3.0** |
| `@hyperframes/producer` | 0.2.5 | **0.3.0** |
| `@hyperframes/studio` | 0.2.9 | **0.3.0** |
Between 0.2.5 and this release, `player` and `studio` received 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/player`
**Restored package entry points to the compiled `dist/` output.** 0.2.5 shipped with `"main": "./src/hyperframes-player.ts"` but the published tarball only included `dist/` via the `"files"` field. Every consumer trying to import the package failed with `Module not found: Can't resolve '@hyperframes/player'`. Entry points now point at the built JS/`.d.ts` files inside `dist/`.
**DOM-based root timeline resolution in the ready probe.** In a bundled preview, `window.__timelines` contains the master composition alongside its sub-compositions, for example:
```js
{
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 the `ready` event 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/studio`
**`useTimelinePlayer.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.tsx` loads `@hyperframes/player` lazily.** The component used to call `import "@hyperframes/player"` at module scope, which runs the package's `customElements.define(...)` side effect during module evaluation. `HTMLElement` does 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 `.js` extensions.** Files under `src/captions/` imported siblings as `./types.js` and `./parser.js`. That is legal ESM TypeScript but Turbopack and several other bundlers refuse to resolve those specifiers against `.ts` files inside `node_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/producer`
Version 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/studio` in 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/player` directly:
- Consumer bundlers can resolve the package again (dist entry points restored).
- The `ready` event duration reports the master, not a sub-composition.
## After merge
Publish each package to npm with `pnpm publish` (workspace deps auto-resolve).
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.
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
@hyperframes/cli@hyperframes/core@hyperframes/engine@hyperframes/player@hyperframes/producer@hyperframes/studioBetween 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: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: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:Cannot resolve './types.js'.If you use
@hyperframes/playerdirectly:readyevent duration reports the master, not a sub-composition.After merge
Publish each package to npm with
pnpm publish(workspace deps auto-resolve).