James RussoandClaude Opus 5.5
f55b366175
* fix(build): ship NodeNext-resolvable declarations from every package tsc copies relative specifiers verbatim, so packages whose sources use bundler-style extensionless imports (core, inspector) published .d.ts files that a module/moduleResolution nodenext consumer cannot resolve. Core already rewrote its emitted JavaScript for this, but not its declarations. Move that rewrite to scripts/rewrite-relative-import-extensions.mjs, make it cover .d.ts too (adding .js or /index.js, and failing the build when a declaration import has no declaration), and run it after every tsc emit: core, engine, sdk, producer, aws-lambda, gcp-cloud-run and inspector. verify:packed-manifests now typechecks the clean packed consumer with skipLibCheck false and type-only imports of every typed subpath, so an unresolvable import inside a published declaration fails the gate and is attributed to its package. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * chore(ci): allow the moved core rewrite-esm-extensions script deletion Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * ci: rebuild the edit-accuracy bench when the import-extension rewriter changes The package builds now run scripts/rewrite-relative-import-extensions.mjs, so main's edit_accuracy paths filter has to include it (check-edit-accuracy-filter test). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
K8s / Cloud Run / ECS reference Dockerfile
This directory ships a reference Dockerfile.example for adopters who want to run HyperFrames distributed renders outside AWS Lambda. The image bakes Node 22 + bun + chrome-headless-shell + ffmpeg + the producer source, and works on Kubernetes Jobs, Argo Workflows, Cloud Run Jobs, ECS Fargate, or plain docker run.
We do not publish this image to a registry — the OSS contract is that adopters build it themselves so Chrome / ffmpeg / producer versions stay pinned to the source checkout they audited, not a floating tag we'd have to keep in sync with every release.
Build
From the repo root:
docker build -t hyperframes-chunk-runner:local -f examples/k8s-jobs/Dockerfile.example .
The build pulls chrome-headless-shell via @puppeteer/browsers and installs Debian system packages for the Chromium ABI deps. Expect about 2.8 GB unpacked.
Use
The producer's distributed primitives are pure functions over local paths. Wire them into your orchestrator however you like. In the image, run them with bun from /app/packages/aws-lambda (the Dockerfile header shows the docker run line):
import { plan, renderChunk, assemble } from "@hyperframes/producer/distributed";
// Controller-side: produce a self-contained planDir + content-addressed planHash.
const planResult = await plan(projectDir, config, planDir);
// Worker-side: render one chunk (byte-identical on retry for the same input).
const chunk = await renderChunk(planDir, chunkIndex, outputChunkPath);
// Controller-side: stitch chunks into the final deliverable.
await assemble(planDir, chunkPaths, audioPath, outputPath);
A typical Kubernetes Jobs orchestration:
- Controller runs a one-shot Job that mounts the project directory + calls
plan(). Uploads the resultingplanDir/to your shared storage (S3, GCS, PVC, …). - Per-chunk Jobs (one per chunk index) download the planDir, call
renderChunk(planDir, i, output), upload the output. Argo Workflows'withSequenceis a natural fit. - Assembler Job downloads the planDir + every chunk output, calls
assemble(...), uploads the final mp4 / mov.
The AWS Lambda implementation in packages/aws-lambda/src/handler.ts is one concrete adapter — read it as a reference for the per-activity event shape.
Lambda?
If you want AWS Lambda specifically, use hyperframes lambda deploy instead — it ships a turnkey deployment. See docs/deploy/aws-lambda.mdx.