Six findings from a third max-effort code review, focused on the previous commit's fixes: 1. --batch-concurrency N>=2 runs genuinely concurrent renderLocal() calls (Promise.all workers in batchRender.ts), which can't safely share the trial's one process-wide env var + module flag — a row finishing first could tear down the env var/flag mid-render for a sibling row still in flight. Rather than attempt to make shared process-global state safe under real concurrency, added RenderOptions.disableDeParallelRouterTrial and set it whenever batchConcurrency > 1 — the trial simply isn't offered when it can't be evaluated safely. 2. maybeConsumeDeParallelRouterTrial's "outcome === undefined" no-op guard almost never fired: aggregateDrawElement (perfSummary.ts) defaults parallelRouter to the string "none" for every render, whether or not drawElement/the router ever engaged — never undefined. Every ordinary render below the router's own frame threshold (the common case) was ticking the render-count backstop, tripping DE_PARALLEL_ROUTER_TRIAL_MAX_RENDERS after 25 completely unrelated renders that never touched the router. Now treats "none" the same as undefined. 3. isDeParallelRouterTrialBlocked relied solely on shouldTrack(), which memoizes its verdict once per process — during a long --batch run, a `hyperframes telemetry off` issued from another terminal mid-batch would never be observed. Restored a direct config.telemetryEnabled check (read fresh every call, unlike shouldTrack()'s cache) alongside it. 4. maybeConsumeDeParallelRouterTrial's config write had no way to detect a losing race against a concurrent process — added a verify-and-retry loop (write, re-read fresh, retry up to 3x if a concurrent writer landed in between) that narrows the window further without a full file-locking rewrite. 5. The trial could arm before the first-run telemetry disclosure (showTelemetryNotice) was guaranteed to have printed — that notice runs via a fire-and-forget, unawaited dynamic import in cli.ts with no ordering guarantee relative to the render command. Rather than touch that pre-existing async bootstrap chain, gated the trial on config.telemetryNoticeShown: it simply never offers itself on a fresh install's very first invocation. 6. Added a dedicated config.test.ts exercising readConfig/readConfigFresh/ writeConfig through the REAL module (node:fs mocked with an in-memory fake, not a HOME-env hack) — readConfigFresh's cache-bypass and the type-guarded boolean/number parsing had zero coverage through the real implementation before this. Also fixed the test fixture that was supposed to cover finding #2 but used an unrealistic `drawElement: {}` shape instead of the real `{ parallelRouter: "none" }` aggregateDrawElement actually produces. Extracted applyDeParallelRouterOutcome to keep maybeConsumeDeParallelRouterTrial under the repo's complexity gate after adding the retry loop. 11 new/updated tests in render.test.ts (56 total) + 7 new tests in config.test.ts. Verified against fallow's audit gate clean. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
hyperframes
CLI for creating, previewing, and rendering HTML video compositions.
Install
npm install -g hyperframes
Or use directly with npx:
npx hyperframes <command>
Requirements: Node.js >= 22, FFmpeg
Commands
init
Scaffold a new Hyperframes project from a template:
npx hyperframes init my-video
cd my-video
preview
Start the live preview studio in your browser:
npx hyperframes preview
# Studio running at http://localhost:3002
npx hyperframes preview --port 4567
render
Render a composition to MP4. Run from the project directory; the positional
argument is the project directory (not a file), so render the project's
index.html directly, or point at a specific composition file with -c:
npx hyperframes render -o output.mp4
npx hyperframes render -c ./my-composition.html -o output.mp4
lint
Validate your Hyperframes HTML:
npx hyperframes lint ./my-composition
npx hyperframes lint ./my-composition --json # JSON output for CI/tooling
npx hyperframes lint ./my-composition --verbose # Include info-level findings
By default only errors and warnings are shown. Use --verbose to also display informational findings (e.g., external script dependency notices). Use --json for machine-readable output with errorCount, warningCount, infoCount, and a findings array.
compositions
List compositions found in the current project:
npx hyperframes compositions
benchmark
Run rendering benchmarks:
npx hyperframes benchmark ./my-composition.html
doctor
Check your environment for required dependencies (Chrome, FFmpeg, Node.js):
npx hyperframes doctor
browser
Manage the bundled Chrome/Chromium installation:
npx hyperframes browser
info
Print version and environment info:
npx hyperframes info
docs
Open the documentation in your browser:
npx hyperframes docs
upgrade
Check for updates and show upgrade instructions:
npx hyperframes upgrade
npx hyperframes upgrade --check --json # machine-readable for agents
Documentation
Full documentation: hyperframes.heygen.com/packages/cli
Related packages
@hyperframes/core— types, parsers, frame adapters@hyperframes/engine— rendering engine@hyperframes/producer— render pipeline@hyperframes/studio— composition editor UI