The Lambda adapter has been on `main` since PR #909 but its package
manifest still shipped TypeScript source (`main: ./src/index.ts`,
`build: tsc --noEmit`, `version: 0.0.1`) and the publish workflow
didn't list it. This wires it up to publish alongside the other
`@hyperframes/*` packages on the next `v*` tag.
Changes:
- **packages/aws-lambda/build.mjs (new)** — mirrors
`packages/producer/build.mjs`: esbuild bundles four entry
points (`src/index.ts`, `src/handler.ts`, `src/sdk/index.ts`,
`src/cdk/index.ts`) → `dist/`, then `tsc --emitDeclarationOnly`
emits .d.ts via `tsconfig.build.json`. All runtime/peer deps
(@aws-sdk/*, @hyperframes/producer*, @sparticuz/chromium,
aws-cdk-lib, constructs, ffmpeg-static, ffprobe-static,
puppeteer-core, tar) are external so consumers resolve them
through their own node_modules.
- **packages/aws-lambda/tsconfig.build.json (new)** — drops the
workspace `paths` overrides so `@hyperframes/producer*`
resolves through node_modules to producer's already-built
`dist/` types instead of pulling its full source tree into
emit (which would violate `rootDir`).
- **packages/aws-lambda/tsconfig.json** — keeps `noEmit: true`
+ workspace `paths` for fast in-place typechecks; also
excludes `src/**/__fixtures__/**` so test-only helpers
(fakeS3) don't leak into emitted declarations.
- **packages/aws-lambda/package.json**:
* version bumped 0.0.1 → 0.6.18 (matches the repo's lockstep
release cadence)
* main / types / exports map points at `dist/...`
* files: ["dist/", "scripts/", "README.md"] (scripts/ kept
whole because build-zip.ts and verify-zip-size.ts both
import scripts/_formatBytes.ts)
* scripts.build = `node build.mjs`
- **package.json** — root `build` filter includes
`aws-lambda` so `bun run build` builds it in topological
order after producer.
- **.github/workflows/publish.yml** — one new
`publish_pkg "@hyperframes/aws-lambda" "@hyperframes/aws-lambda"`
line. First publish is automatic via the `--access public` flag
in `publish_pkg`; the @hyperframes scope already owns the name.
Verification:
bun run build # full root build green
bun run verify:packed-manifests # aws-lambda passes
pnpm pack packages/cli # @hyperframes/aws-lambda
# rewrites workspace:* → 0.6.18
npm install -g <cli-tgz> # smoke-install still works
hyperframes lambda deploy # friendly missing-package
# error still fires when
# aws-lambda isn't installed
## Summary
- Add comprehensive README for `@hyperframes/player` covering installation, usage, full API reference (attributes, properties, methods, events), sizing, and distribution formats
- Bump version from 0.2.2 to 0.2.4 to align with monorepo release
## Test plan
- [x] Verify README renders correctly on GitHub
- [x] Confirm package.json version matches monorepo (0.2.4)
The 3-workflow chain (release.yml → release-tag.yml → publish.yml) was
broken by design: tags created by GITHUB_TOKEN don't trigger other
workflows, so merging a release PR never actually published.
Consolidate into a single publish.yml that triggers on both tag push
and release PR merge. Delete the redundant prepare-release and
tag-release workflows.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Reverting the package rename — Vance needs @hyperframes/cli for local
dev workflow. Instead, rewrite the name to "hyperframes" in the publish
workflow just before npm publish, so the monorepo name stays intact.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The CLI is published to npm as unscoped `hyperframes` but the
package.json had `@hyperframes/cli`, causing ENEEDAUTH on publish
(wrong scope for the npm token).
Also replace per-step continue-on-error with a single publish script
that skips already-published versions and fails on real errors, making
re-runs safe.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
## Summary
- rewrite workspace protocol dependencies to publish-safe semver ranges before the npm publish workflow runs
- keep workspace protocol references in source manifests for normal monorepo development
- ensure the published `@hyperframes/producer` manifest no longer ships unresolved `workspace:` deps
## Why
The internal repo hit a Docker build failure because the published `@hyperframes/producer` metadata still contained `workspace:^` dependencies for `@hyperframes/core` and `@hyperframes/engine`. `npm install` cannot resolve those outside the monorepo, so the published package itself was the root cause.
## Validation
- `bun install --frozen-lockfile`
- `bun run build:producer`
- `bun run prepare:publish-manifests`
- `npm pack --workspace packages/core`
- `npm pack --workspace packages/engine`
- `npm pack --workspace packages/producer`
- installed the three tarballs together in a clean temp project with `npm install --ignore-scripts`
- extracted the producer tarball and verified its `package.json` contains `^0.1.3` for `@hyperframes/core` and `@hyperframes/engine`, not `workspace:^`
Already-published versions cause npm to return E403. With
continue-on-error, the workflow skips published packages and
continues to publish the remaining ones. Safe to re-run.
npm provenance requires a public GitHub repo. The repo is currently
set to "internal" visibility, which causes E422 on publish.
Remove --provenance until the repo is made public.
- Remove pnpm/action-setup (no pnpm-lock.yaml exists after bun migration)
- Remove cache: pnpm from setup-node (caused "lockfile not found" error)
- Use bun for install/build, npm for publish (npm comes with node)
- Pass NODE_AUTH_TOKEN per publish step
* fix(ci): update publish workflow to use bun install
pnpm-lock.yaml was removed in the bun migration but publish.yml
still referenced it. Use bun for install/build, keep pnpm for
publish (publishConfig overrides + --provenance).
* docs: update stale pnpm references to bun across docs and scripts
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
James