Thanks to visit codestin.com
Credit goes to github.com

Skip to content

chore: release v0.3.0 - #249

Merged
miguel-heygen merged 1 commit into
mainfrom
chore/release-v0.3.0
Apr 13, 2026
Merged

miguel-heygen merged 1 commit into
mainfrom
chore/release-v0.3.0

Conversation

@miguel-heygen

@miguel-heygen miguel-heygen commented Apr 13, 2026

Copy link
Copy Markdown
Collaborator

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:

{
  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).

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).
@miguel-heygen
miguel-heygen merged commit 58ddb11 into main Apr 13, 2026
21 checks passed
@miguel-heygen
miguel-heygen deleted the chore/release-v0.3.0 branch April 13, 2026 23:22
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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants