ci: publish complete pr-package dependency graph

[patrikduksin]

Installing a PR build of alchemy from pkg.ing currently breaks: the tarball keeps workspace:* references for its nine runtime dependencies, so consumers fall back to stale or missing npm versions. This PR makes every pr-package publish a complete, installable same-commit graph — bun add alchemy@<pkg.ing url> just works — by pointing the caller at the graph-aware workflow from actions#2 and listing the nine workspace dependencies.

Summary

• pin the reusable PR-package workflow to the merged duplicate-edge fix from alchemy-run/actions#5
• publish alchemy's complete same-commit runtime workspace dependency closure: six Distilled packages and three Cloudflare Tools packages
• run every added package build on ubuntu-22-large, matching the existing project-reference build requirements

Why

An official pkg.ing alchemy tarball currently retains workspace:* references for nine runtime dependencies because those packages are absent from this caller's package list. Consumers can therefore silently fall back to stale npm versions—or fail when no matching npm package exists—instead of installing a coherent same-commit graph. The graph support merged in actions#2 can rewrite and publish those dependencies once the caller declares the full closure.

This remains a static list: whenever alchemy gains another workspace dependency in dependencies, optionalDependencies, or peerDependencies, this workflow must grow too or the graph will silently become incomplete again. As a non-blocking follow-up, the actions repository could derive the transitive runtime closure directly from workspace manifests.

Bun compatibility and CI cost

Complete graphs introduce duplicate tarball-URL edges. Bun through 1.3.14 (including the affected canary) drops a late duplicate edge's callback and fails installation with failed to resolve. A maintainer-verified fix is open in oven-sh/bun#35426; the exact deep-graph repro and verification are recorded here, but the fix is not yet released.

This is not hypothetical for this graph: we ran this exact configuration through the pinned workflow scripts against a private pkg.ing-compatible host, and installing the original published graph failed 6/6 attempts on Bun 1.3.14 (evidence in the comments below — the graph itself is byte-correct; each URL installs fine standalone). The actions-side fix in alchemy-run/actions#5 gives each affected duplicate edge a deterministic parent-specific tag such as graph-<sha>-from-<parent>, uploads the same tarball bytes under every required tag, and rewrites the edge to that tag path. The resulting graph installed successfully in 3/3 fresh Bun 1.3.14 projects. Query-string identities are intentionally not used because Bun retains ? in its package-store path and can then misparse that path during runtime module resolution. actions#5 is now merged, and this PR pins its merge commit (1d5b072da6efc338810ec99e1fd7d716947e6b57).

This also adds nine package builds per push on large runners. That cost is explicit so maintainers can weigh complete graph correctness against CI usage.

Verification

• parsed the workflow YAML
• independently derived the runtime workspace closure using the publisher's three-root algorithm and confirmed the added nine entries match exactly
• confirmed every configured directory exists, every manifest name matches, and every entry uses ubuntu-22-large
• confirmed 1d5b072da6efc338810ec99e1fd7d716947e6b57 is the merged alchemy-run/actions#5 commit
• git diff --check

actionlint was not installed locally; bunx actionlint did not expose a runnable binary, so no actionlint result is claimed.

[patrikduksin]

Locally exercised the PR-package workflow from alchemy-run/actions@62a67005a23141320978751259c2342a01333bdd against pkg.patrikduksin.com, using alchemy-run/alchemy upstream/main at 016c375061706811664c7a1f0c36a0d948173cca (submodules: cloudflare-tools 0882b5ca2b00cb3349bff056f7547bf045495088, distilled c18cbf11b61e5223380107a98e6c7b1c822baddb). No CI, commits, pushes, or comments.

I followed the pinned reusable workflow's actual ordering: plan-pr-packages.ts, the caller's exact build command for each of the 12 configured packages, pack-pr-package.ts (which performs the workspace rewrite immediately before packing), then publish-pr-package-graph.ts. The compatibility-only rewrite-pr-package-deps.ts is not called by this pinned workflow. I did not invoke comment-pr-packages.ts because that would post; I derived its URL directly from the plan instead.

Local substitutions for GitHub contexts/actions:

• synthetic push context with SHA=016c375... and collision-safe BRANCH=local-upstream-test-016c375 (rather than overwrite main/PR tags); the plan selected all 12 packages
• Actions artifact upload/download was mirrored by copying each package's sole .tgz into .pr-packages/<plan artifact name>/
• matrix jobs ran sequentially in one isolated scratch checkout
• PR_PACKAGE_HOST and INSTALL_HOST were both pkg.patrikduksin.com; the token came from the local auth file; every upload used TTL=1 hour
• local toolchain was Bun 1.3.14 and Node 26.5.1 (the workflow's setup default is Node 24)

Results:

• 12/12 builds and packs succeeded; dependency tags were uploaded for the complete set before public tags
• before upload, graph-016c375..., 016c375, the full SHA, and the synthetic branch tag were absent, so they did not collide with the production graph-c967e1d4... set
• 12/12 graph URLs and 12/12 public URLs returned HTTP 200
• all 12 expected package names are present in the packed graph
• zero workspace: references remain in any packed runtime manifest
• all 18 rewritten graph dependency URLs use pkg.patrikduksin.com and the same full-commit tag graph-016c375061706811664c7a1f0c36a0d948173cca

Install URL (derived exactly like the PR comment):

bun add alchemy@https://pkg.patrikduksin.com/alchemy/016c375

Installing the published graph failed in 5/5 fresh projects on Bun 1.3.14 (a sixth independent attempt also failed — 6/6 total): the duplicate-tarball-URL race, not a flake. The errors varied by run but were consistently false resolution failures for repeated identical URLs, chiefly:

error: @distilled.cloud/core@https://pkg.patrikduksin.com/@distilled.cloud/core/graph-016c375061706811664c7a1f0c36a0d948173cca failed to resolve
error: @distilled.cloud/cloudflare-rolldown-plugin@https://pkg.patrikduksin.com/@distilled.cloud/cloudflare-rolldown-plugin/graph-016c375061706811664c7a1f0c36a0d948173cca failed to resolve

This is not an upload/graph correctness failure: those URLs returned 200, their packed manifests are correct, and a clean standalone bun add @distilled.cloud/core@https://pkg.patrikduksin.com/@distilled.cloud/core/graph-016c375061706811664c7a1f0c36a0d948173cca succeeded. Standalone better-auth and pr-package installs reached the same alchemy graph and reproduced the same race. This is direct evidence for adding per-edge ?from= disambiguation as described in the PR.

[patrikduksin]

Converting to draft: we found a bug in this PR's own recommendation and are fixing it before this is ready.

The description suggests query-string disambiguation (?from=<parent>) for the duplicate-URL install race. Don't implement that variant — it trades an install-time failure for a runtime one: Bun keeps the literal ? in its package-store directory name and later misparses that path during module resolution, so the graph installs but the installed CLI fails to resolve its own modules (observed on Bun 1.3.14).

The safe form is publishing the same tarball bytes under an additional per-edge alias tag (e.g. graph-<sha>-from-<parent>) and pointing the dependent's URL at that tag path — unique URL strings still avoid the oven-sh/bun#35426 race, and store paths stay clean. We've verified this end-to-end on a pkg.ing-compatible host: the previously 6/6-failing clean-room install passes, no ? store paths, and the installed CLI runs under Bun.

We're preparing an actions-side implementation of the tag variant and will update this PR's description and pin once it's ready.

[patrikduksin]

Blocker verification complete and this PR is ready for review.

• rebased onto current main and resolved the workflow conflict
• pinned the merged duplicate-edge fix from alchemy-run/actions#5 at 1d5b072da6efc338810ec99e1fd7d716947e6b57
• rechecked the current 12-package graph on Bun 1.3.14: 19 workspace edges, four duplicated dependency targets, zero URL collisions, and zero query-string paths
• authoritative CI passed: bun tsc -b and bun run docs:check
• GitHub reports the PR as mergeable and clean

The PR-package jobs are skipped as expected because this PR originates from a fork.