INT-04 (#181). This documents what is publish-ready, the order, and the one open design question. Nothing here publishes anything: the workflow is manual-only and the owner dispatches it after review.
| Package | Spec | Status | Notes |
|---|---|---|---|
|
|
LIVE 0.1.2 (2026-05-20) |
The ADR-019 compiler shim. Cross-runtime (Deno
+ Bun + Node — only repo package with a documented runtime carve-out
from the Deno-only policy). Licensed |
|
|
dry-run OK; not yet published |
Loader + marshal + runtime + ownership accessor.
Tests excluded via |
|
|
dry-run OK; not yet published |
TEA runtime. Depends on
|
Publish order is load-bearing for the JS-runtime pair: affine-js
must publish before affinescript-tea (the latter resolves
@hyperpolymath/affine-js/loader). affinescript-cli has no JSR-side
dependencies and publishes independently of either.
affinescript-dom is AffineScript source (.affine), not a JS package
— it is consumed by the compiler, not JSR; out of scope for JSR.
The JS entrypoints emit JSR’s unsupported-javascript-entrypoint
(slow-types) warning — expected for a JS-with-JSDoc package; it
publishes, only @hyperpolymath/affine-js’s fast-check is skipped.
`types.d.ts already provides the consumer-facing contract. Converting
entrypoints is out of scope for INT-04 (tracked separately if desired).
-
Review
deno publish --dry-run(CI:Publish to JSR (manual)withdry_run: true, or locallycd <pkg> && deno publish --dry-run). -
Dispatch
.github/workflows/publish-jsr.ymlforaffine-jswithdry_run: false(JSR OIDC viaid-token: write— no token secret). -
Then dispatch it for
affinescript-tea.
"then npm" (#181) is a separate, later step and is not wired by
this prep. If/when needed it follows the existing owner-sanctioned npm
pattern (.github/workflows/affine-vscode-publish.yml, NPM_TOKEN
scoped automation token) — a deliberate exception to Deno-first.
#181 says "publish compiler + runtime". The runtime is the JS packages above. The compiler is a native OCaml binary — not a JSR/npm package. The one-way-door fork (#260) was decided (ADR-019): Releases-canonical, dual-channel. Full decision record: docs/decisions/0019-compiler-distribution.adoc.
-
Canonical artifact.
.github/workflows/release.yml(#260 S2), on av*tag, buildsaffinescript-{linux-x64,macos-x64,macos-arm64}raw binaries + aSHA256SUMSmanifest attached to the GitHub Release. (windows-x64is a tracked follow-up.) Asset names are the ADR-019 contract — do not rename without amending the ADR + the shim. -
Ergonomic front door.
packages/affinescript-cli(@hyperpolymath/affinescript, #260 S3) — a thin Deno shim that downloads the host-triple binary from the Release pinned inpins.js, verifies it against the embedded SHA-256 (fail-closed: an unpinned/mismatched binary is never executed), caches it under$AFFINESCRIPT_CACHE/XDG, and execs it with the caller’s argv. One compiler version + checksum per shim release (no floating fetch). Publish is owner-gated viapublish-jsr.yml(the INT-04 manual workflow; choiceaffinescript-cli). -
Later, additive over the same Release artifact (not separate producers): Guix/Nix fetch-derivations; an npm tail only if an npm-native consumer needs it.
affinescript-lsp distribution (INT-10, #282) consumes the shim.
End-to-end live since 2026-05-20: v0.1.1 Release published (3 binaries
+ SHA256SUMS), pins.js finalised, shim 0.1.2 on JSR, LSP SHIM_SPEC
points at jsr:@hyperpolymath/affinescript@0.1.2.
The first publish of a new @hyperpolymath/* package trips five
separate gates (in this order, each failing with an unhelpful error
the next time round):
-
Claim the JSR scope (
@hyperpolymath— one-time per scope, viahttps://jsr.iosign-in). -
Create the package record on JSR —
deno publisherrors Following packages don’t exist… until done. -
Link a trusted GitHub repository at the package or scope level (
https://jsr.io/@<scope>/<package>/settings) — without it, OIDC isactorNotAuthorized. -
SPDX-recognised licence in
deno.json— custom licences need theLicenseRef-*prefix or a switch to a standard SPDX identifier (the shim went the standard route withMPL-2.0). -
Optional but recommended: add a sibling
mod.d.tsAND a/// <reference types="./mod.d.ts" />triple-slash comment inmod.jsso JSR fast-check finds the types. The.d.tsalone is not enough — JSR doesn’t auto-detect.
Dry-run only catches step 4 and step 5; steps 2 and 3 fail at real publish time. Subsequent version bumps after the first publish need only the version-string change.