Downstream report from the Stacks side, where craft is declared as a pantry dependency and the install 404s. Filing here because the fix is a distribution decision only craft can make.
What happens
Scaffolded Stacks apps carry this in config/deps.ts:
dependencies: { craft: "^0.0.1", ... }Pantry resolves the bare name craft to the domain-style package craft-native.org, and every build that goes through the ./buddy wrapper then dies at install:
pantry install v0.11.96 (2fb25bbdf)
Found 3 package override(s)
Download HTTP 404
- craft-native.org@^0.0.1 (RegistryArtifactNotFound)
1 package(s) failed to installIt is not a dropped version. Nothing is published under that name at all:
$ curl -o /dev/null -w "%{http_code}" https://dist.pkgx.dev/craft-native.org/versions.txt # 404
$ curl -o /dev/null -w "%{http_code}" https://dist.pkgx.dev/craft-native.org/linux/x86-64/versions.txt # 404
$ curl -o /dev/null -w "%{http_code}" https://dist.pkgx.dev/craft-native.org/darwin/aarch64/versions.txt # 404
$ curl -o /dev/null -w "%{http_code}" https://dist.pkgx.dev/bun.sh/versions.txt # 200 (control)The npm package is healthy and current (craft-native, latest 0.0.247, 162 versions), which matches the README: bun add craft-native. So the gap is specifically the pantry/registry channel, which the README does not claim to support but which consumers are being pointed at by that bare craft entry.
Cost
One app in our estate stopped deploying for three days behind this, with no symptom other than a red build job, because its deploy stage needs build. Four of our six declare the line.
It also appeared without any code change on our side. The dependency has been in the file since the repo was scaffolded in July and CI was green with it on 2026-10-16; by 2026-10-19 every run failed. The workflow installs pantry from releases/latest, unpinned, so a new pantry resolved the name differently underneath us. Your own pantry.jsonc already guards against exactly this, and the comment there says it well:
Pinned exactly, and deliberately not "latest": 1.4.x writes
lockfileVersion: 2, which 1.3.x cannot parse, so "latest" would break every 1.3-based checkout and CI job the day 1.4.0 publishes.
A second, separable bug in that constraint
^0.0.1 does not mean "0.0.x". For a 0.0.z version the caret pins the patch, so it matches only 0.0.1:
^0.0.1 satisfied by 0.0.1 : true
^0.0.1 satisfied by 0.0.2 : false
^0.0.1 satisfied by 0.0.247 : false
^0.0.1 satisfied by 0.1.0 : falsecraft is on v0.0.247. So even with the registry serving the package, that constraint could never pick up anything after the very first release. Worth a line in the docs for anyone pinning a 0.0.x craft, since the intuitive reading is the wrong one.
The ask
Either of these resolves it, and the choice is yours:
- Publish craft to the registry as
craft-native.org, so a pantry dependency resolves; or - State that pantry is not a supported consumer channel (it is for craft's own build deps:
bun.sh,ziglang.org) so that scaffolds stop declaringcraftthere and usebun add craft-nativeinstead.
Flagging it now rather than just deleting the line downstream, because native and mobile are moving into scope for our 1.0 rather than out of it, so this dependency is about to matter more. If (2) is the answer, I am happy to take the scaffold change to the Stacks side.
Tracked downstream as stacksjs/stacks#2919. Our temporary workaround is to put craft behind the opt-in gate the other system binaries already sit behind, which restores the build without removing the intent.