Repository navigation
bun install fails intermittently in CI/CD: @solidjs/start pinned to flaky pkg.pr.new registry (404) #46629
Description
Description
bun install intermittently fails with 404 Not Found when resolving @solidjs/start, which is pinned to https://pkg.pr.new/@solidjs/start@dfb2020 in the root package.json catalog. This breaks containerized CI/CD builds that run bun install against the opencode monorepo.
pkg.pr.new is StackBlitz's on-demand PR-preview npm registry. It intermittently 404s due to rate-limiting and cold-start behavior (it builds packages from GitHub PR commits on demand). The 404s are transient — the URL may return 200 minutes later — but they reliably break CI pipelines that can't tolerate flaky dependency resolution.
The pkg.pr.new artifact comes from solidjs/solid-start PR #2015 ("temporary clone all responses"), whose author explicitly wrote:
"ignore this PR i need to do this to test something with pkg pr"
This is a throwaway test PR, not a meaningful feature PR. The latest published @solidjs/start on npm is 2.0.4 and is the correct source.
This was previously raised in #27422 but was auto-closed as a "question" by the issue triage bot. Filing as a bug per CONTRIBUTING.md guidelines.
Plugins
N/A — build/dependency issue, not plugin-related.
OpenCode version
v1.18.18 through v1.18.25 + dev branch HEAD (all still pin the pkg.pr.new URL at package.json:89).
Steps to reproduce
- Clone opencode at any tag from v1.18.18 onward (or
devHEAD) - Run
bun installin a CI/CD container or any environment where pkg.pr.new rate-limits or cold-starts - Observe:
error: failed to download @solidjs/start@https://pkg.pr.new/@solidjs/start@dfb2020: 404 Not Found bun installexits 1; build fails
The failure is intermittent — re-running may succeed (the URL returns 200 when pkg.pr.new is not rate-limiting). But it fails frequently enough to block CI pipelines (observed twice in a single day in our production CI).
Screenshot and/or share link
Error output from CI:
error: failed to download @solidjs/start@https://pkg.pr.new/@solidjs/start@dfb2020: 404 Not Found
Operating System
Linux (Docker, debian:bookworm-slim builder stage)
Terminal
CI/CD (GitHub Actions, self-hosted runners)
Proposed fix
Switch the catalog entry from the pkg.pr.new URL to the published npm version:
- "@solidjs/start": "https://pkg.pr.new/@solidjs/start@dfb2020",
+ "@solidjs/start": "2.0.4",A fix PR is available at: dev...padraig-myers-sh:opencode:fix/solidjs-start-published-version
Activity
github-actions commentedon Sep 1, 2026
This issue might be a duplicate of an existing issue. Please check:
@solidjs/startpinned topkg.pr.newregistry causing CI/CD build failures. That issue was auto-closed by the triage bot as a question, but covers the identical dependency problem.opencodejr commentedon Oct 28, 2026
Thanks for the detailed report. I checked the latest
dev(f822b107e), and the rootpackage.jsoncatalog still pins@solidjs/starttohttps://pkg.pr.new/@solidjs/start@dfb2020, so the dependency you describe is still there.I couldn't get the 404 to happen, though:
bun installruns of a project depending on the same URL all succeeded.Since the failure is intermittent and comes from pkg.pr.new, it probably depends on network conditions in your CI. These would help:
bun installoutput from a failing run, including the Bun version.Only
packages/console/appandpackages/stats/appuse@solidjs/start; the CLI doesn't. Whether to move the pin to a published release, as in your proposed change, is up to the maintainers, since the pinned preview build may include changes the console app relies on.Related: #27422 raised the same pin earlier and was closed automatically as a question.
opencodejr commentedon Oct 31, 2026
Closing this for now. We asked for more details from a failing CI run and didn't hear back. In our tests the pinned
https://pkg.pr.new/@solidjs/start@dfb2020URL returned 200 every time, and cold-cachebun installruns all succeeded, so we couldn't reproduce the 404. The pin is still ondev, though.If it keeps happening, please reply here or open a new issue with:
bun installoutput from a failing run, including the Bun versionThen we can take another look. Thanks for the report and the proposed change.