Skip to content

Remove unused bun-tracestrings dependency - #25425

Closed
dylan-conway wants to merge 2 commits into
mainfrom
claude/remove-bun-tracestrings
Closed

dylan-conway wants to merge 2 commits into
mainfrom
claude/remove-bun-tracestrings

Conversation

@dylan-conway

Copy link
Copy Markdown
Member

Summary

  • Removes the unused bun-tracestrings devDependency from package.json

Test plan

  • Verify dependency is removed from package.json

🤖 Generated with Claude Code

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@github-actions github-actions Bot added the claude label Dec 9, 2025
@robobun

robobun commented Dec 9, 2025 •

Copy link
Copy Markdown
Collaborator
Updated 6:51 PM PT - Dec 8th, 2025

❌ @dylan-conway, your commit 2b1f955 has 5 failures in Build #33061 (All Failures):


🧪   To try this PR locally:

bunx bun-pr 25425

That installs a local version of the PR into your bun-25425 executable, so you can run:

bun-25425 --bun

@coderabbitai

coderabbitai Bot commented Dec 9, 2025 •

Copy link
Copy Markdown
Contributor

Walkthrough

Removed the bun-tracestrings devDependency from package.json. No additional dependencies were added and no runtime or behavioral logic modifications were introduced.

Changes

Cohort / File(s) Change Summary
Dependency removal
package.json
Removed bun-tracestrings devDependency

Suggested reviewers

  • nektro
  • taylordotfish

Pre-merge checks

✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately and clearly describes the main change: removing an unused dependency from package.json.
Description check ✅ Passed The PR description includes both required template sections with substantive content, though using a different format than the template structure.

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Disabled knowledge base sources:

  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between f25ea59 and bc2cd1f3589131a104d965b0457fb11e16758298.

⛔ Files ignored due to path filters (1)
  • bun.lock is excluded by !**/*.lock
📒 Files selected for processing (1)
  • package.json (0 hunks)
💤 Files with no reviewable changes (1)
  • package.json

Comment @coderabbitai help to get the list of available commands and usage tips.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@dylan-conway
dylan-conway force-pushed the claude/remove-bun-tracestrings branch from bc2cd1f to 2b1f955 Compare December 9, 2025 02:04
Comment thread bun.lock

"buffer-equal-constant-time": ["buffer-equal-constant-time@1.0.1", "", {}, "sha512-zRpUiDwd/xk6ADqPMATG8vc9VPrkck7T07OIx0gnjmJAnHnTVXNQG3vfvWNuiZIkwu9KrKdA1iJKfsfTVxE6NA=="],

"bun-tracestrings": ["bun-tracestrings@github:oven-sh/bun.report#912ca63", { "dependencies": { "@octokit/webhooks-methods": "^5.1.0", "@sentry/types": "^7.112.2", "@types/bun": "^1.2.6", "html-minifier": "^4.0.0", "lightningcss": "^1.24.1", "marked": "^12.0.1", "octokit": "^3.2.0", "prettier": "^3.2.5", "typescript": "^5.0.0" }, "bin": { "ci-remap-server": "./bin/ci-remap-server.ts" } }, "oven-sh-bun.report-912ca63"],

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could this have been here so you can run bunx ci-remap-server ... type thing? idk if anyone used it tho

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah you're right. I forgot the binary from the package might be the only thing used!

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI stack traces rely on ci-remap-server:

const server = spawn(execPath, ["run", "--silent", "ci-remap-server", execPath, cwd, getCommit()], {

Jarred-Sumner pushed a commit that referenced this pull request Aug 17, 2026
…ls never download from GitHub (#39446)

### Problem
- The "Lint JavaScript" (lint.yml) and "Format" (format.yml) checks go
red on PRs that did not touch anything they check. Their `bun install`
step fails with:
  ```
error: failed to download
bun-tracestrings@github:oven-sh/bun.report#912ca63: HTTP 5xx
  Failed to install 1 package
  ```
Seen on #29642 at 5309742 (a C++ comment change), both attempts of
runs 32040959983 and 32040960113, while other PRs' Lint runs flapped
red/green in the same minutes.
- Cause: `package.json:13` pins `bun-tracestrings` as a `github:`
dependency, so every root `bun install` downloads a tarball from GitHub.
That install runs on a fresh runner (no cache) in lint.yml, format.yml,
rust-lints.yml (4 jobs), bun-types.yml and packages-ci.yml, and in every
build (`scripts/build/codegen.ts` `bun_install`). bun retries a tarball
5 times back to back, which does not cover an outage of a few minutes.
- The only user of the package is `scripts/runner.node.mjs`, which runs
its `ci-remap-server` bin on Buildkite test shards
(`runner.node.mjs:803` on main). Nothing in lint, format, types,
rust-lints or the build uses it. Removing it outright was tried in
#25425 and closed for that reason.

### Fix
- Move the dependency to a new `scripts/ci-remap-server/package.json` (+
`bun.lock`) and drop it from the root `package.json` / `bun.lock` (a
pure removal: 94 lockfile entries, the package and its transitive
closure; the lockfile stays `lockfileVersion: 1`).
- `runner.node.mjs` installs that directory right before starting the
server, through the same `spawnBunInstall` as root and test/ so it uses
the agent's baked install cache, and runs the bin from there. The
install is best-effort like the server start already is: on failure it
warns and the tests run without crash remapping instead of failing the
shard.
- `bootstrap.sh` warms the new directory into the image's install cache
next to root and test/. No image version bump needed: the new lockfile
carries over the exact resolutions the root lockfile had (checked entry
by entry), so the caches baked from the old root lockfile already
contain everything except `@types/bun@1.3.14` and `bun-types@1.3.14`,
which resolved to the workspace packages before and now come from npm.
- New source lint
`test/internal/source-lints/lockfile-registry-only.test.ts`: the root
and test/ lockfiles (the two that every PR's checks and every shard
install) may not contain `github:`, `git+` or tarball-URL resolutions.
`source-lints.yml` now also triggers on `bun.lock` / `test/bun.lock`.
- Why this is the right layer: the failing jobs had no use for the
package, and a retry or cache in lint.yml/format.yml would still leave
GitHub on the install path of rust-lints, bun-types, the build and every
dev's `bun install`, and would still fail during a multi-minute blip.
After this, root installs only talk to the npm registry; the one job
that needs GitHub gets it from a baked cache and degrades gracefully
when it is unavailable.
- Verified:
- `test/internal/source-lints/lockfile-registry-only.test.ts`: fails on
main's `bun.lock` (`bun-tracestrings ->
bun-tracestrings@github:oven-sh/bun.report#912ca63`), passes here, under
`bun bd test`, the system bun and bun 1.3.14 (the version the workflows
pin). Whole `test/internal/source-lints/` passes.
- Root `bun install --frozen-lockfile` (lint.yml's command) with bun
1.3.14 and the debug build: no changes. Fresh checkout with GitHub
unreachable (`GITHUB_API_URL=http://127.0.0.1:1`, empty cache): main
fails with `failed to download bun-tracestrings@github:...
ConnectionRefused`, this branch installs.
- `bun install --frozen-lockfile` in `scripts/ci-remap-server` with bun
1.3.14, canary and the debug build: no changes; `bun run --silent
ci-remap-server` from that directory prints a port and serves `/traces`.
- This PR's own Buildkite build (#100049): every non-Windows shard logs
`scripts/ci-remap-server/package.json` / `86 packages installed` in 0.4
to 1s (the baked cache, as predicted; the root install went from 102
packages to 21), followed by `crash reports parsed on port ...`. The
server came up on 17 of 40 debian+ubuntu x64 shards against 14 of 40 on
main's build #100080: the remaining shards hit the runner's pre-existing
5s startup timeout (`ci-remap server did not start: timeout`), which
this PR does not change and is worth a follow-up of its own.
- Locally, `CI=true node scripts/runner.node.mjs ...` with a cold cache
got a 429 from codeload.github.com for the tarball; the runner warned
`ci-remap server not installed (...), crash reports will not be
remapped`, ran the test and exited 0. Same with the directory removed
(`spawn error`).
- `bun lint`, prettier `--check` on the touched files, `sh -n
scripts/bootstrap.sh`, `bun bd` reconfigure after the root package.json
change.
- Overlaps with #38981 on neighbouring lines of the same block in
`runner.node.mjs` (it changes how the server is killed, this changes
where it is installed and started); either rebases trivially onto the
other.

### Background
- `bun-tracestrings` is the npm name of github.com/oven-sh/bun.report,
the service that turns the trace strings in bun's crash reports back
into stack traces. Its `ci-remap-server` bin is a local copy of that:
`runner.node.mjs` starts it, points every spawned bun at it via
`BUN_CRASH_REPORT_URL`, and prints the remapped traces of any test that
crashed. It is purely diagnostic output; tests still fail on their exit
code without it.
- A `github:` dependency has no registry tarball: bun downloads it from
GitHub on install (and caches it under the same name@resolution key as
registry packages).
- `bootstrap.sh` builds the CI agent images. It clones the repo and runs
`bun install` in root and test/ with `BUN_INSTALL_CACHE_DIR` set, so
test shards install from disk; a package only downloads when its
resolution is not in the baked cache. The `# Version:` header is only
bumped when the image itself must change, which this does not require.
- `test/internal/source-lints/` holds repo-invariant tests that run on a
bare checkout in source-lints.yml (no `bun install`), which is why the
lint lives there and why that workflow's path filter had to learn about
the lockfiles.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants