chore(deps): bump brace-expansion from 2.1.2 to 2.1.3

[dependabot]

Bumps brace-expansion from 2.1.2 to 2.1.3.

Commits

• 878df39 2.1.3
• c8bd93c npm ignore .claude
• d13ff45 fix: backport GHSA-mh99-v99m-4gvg (#130)
• See full diff in compare view

[greptile-apps]

PR author is in the excluded authors list.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
hyperdx-oss	Ignored	Preview	Aug 4, 2026 9:00pm
hyperdx-storybook	Ignored	Preview	Aug 4, 2026 9:00pm

[changeset-bot]

⚠️ No Changeset found

Latest commit: e055938

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

🟢 Tier 1 — Trivial

Docs, images, lock files, or a dependency bump. No functional code changes detected.

Why this tier:

• Bot author: dependabot[bot]

Review process: Auto-merge once CI passes. No human review required.
SLA: Resolves automatically.

Stats

• Production files changed: 1
• Production lines changed: 2
• Branch: dependabot/npm_and_yarn/brace-expansion-2.1.3
• Author: dependabot[bot]

To override this classification, remove the review/tier-1 label and apply a different review/tier-* label. Manual overrides are preserved on subsequent pushes.

[github-actions]

E2E Test Results

❌ Error reading test results: ENOENT: no such file or directory, scandir 'all-test-results'

View full report →

[github-actions]

Deep Review

🔴 P0/P1 — must fix

• yarn.lock:12313 — The root resolutions pin was moved to ^2.1.3 (package.json:79) but the lockfile's sole brace-expansion entry is still keyed brace-expansion@npm:^2.1.2 at version: 2.1.2, so Yarn 4 resolves a descriptor that has no lockfile entry and yarn install --immutable fails with YN0028 in the unit, all four integration-shards, and clickhouse-static-build jobs — while any install that honors the committed lockfile still materializes the pre-patch 2.1.2 for every consumer.
  • Fix: Regenerate the lockfile on this branch with the pinned Yarn 4.13.0 so the entry becomes brace-expansion@npm:^2.1.3 at version: 2.1.3 with a matching checksum, commit it, and confirm with yarn install --immutable.
  • _{correctness, security, testing, maintainability, project-standards}

🟡 P2 — recommended

• .github/workflows/main.yml:24 — The lint job installs with a bare yarn install, so it silently rewrites the lockfile inside the runner and reports green while the four --immutable jobs fail at their install step, splitting the CI signal on exactly this class of desync.
  • Fix: Add --immutable to the lint job's install step so a manifest/lockfile mismatch fails fast in the cheapest job instead of after Docker and build setup.
  • _{testing, correctness, security}
• .yarnrc.yml:5 — npmMinimalAgeGate: 7d applies to brace-expansion because it is absent from npmPreapprovedPackages, and since ^2.1.3 admits no older satisfying release, lockfile regeneration will itself be rejected if 2.1.3 is inside the age window; the publish date could not be checked from this environment.
  • Fix: Confirm 2.1.3 is at least seven days old before regenerating, and if it is not, hold the branch until the window elapses rather than broadening npmPreapprovedPackages.
  • _{correctness, security, project-standards}
• package.json:79 — The resolutions key is the bare package name, so it collapses every requester onto one 2.x release including minimatch@10.2.4, which declares brace-expansion: "npm:^5.0.2" at yarn.lock:21304, and minimatch@3.1.2, which declares ^1.1.7; this coercion predates the PR but is re-affirmed by it.
  • Fix: Scope the pin per requested range (for example "brace-expansion@^2.0.1") so each major line stays on its own patched release, then verify the resulting tree with yarn why brace-expansion.
  • _{security, maintainability}
• packages/api/Dockerfile:16 — The image build runs yarn install --mode=skip-build without --immutable against a BuildKit-cached store, so under the current desync it re-resolves and discards the mutated lockfile rather than failing, leaving the version baked into the image undetermined by the reviewed lockfile.
  • Fix: Add --immutable to the image install so builds fail loudly on lockfile drift and image contents stay attestable from the committed lockfile.

🔵 P3 nitpicks (1)

• package.json:70 — The resolutions block now carries 14 pins, most of them security-motivated overrides, with no inline reference to the advisory or upstream issue that justifies each one, so no future reader can tell which pins are still load-bearing and which have been overtaken by the dependency graph.
  • Fix: Add a short comment or a tracked note recording why each security pin exists and the condition under which it can be dropped.

---

Reviewers (5): correctness, security, testing, maintainability, project-standards

Coverage note: Bash, Grep, and Glob were all non-functional in this environment, so git diff never ran — scope was reconstructed by reading package.json, yarn.lock, .yarnrc.yml, .github/workflows/main.yml, and packages/api/Dockerfile directly at HEAD, and every finding above is anchored to text verified on disk rather than to a diff hunk. The agent-native and learnings-researcher reviewers were not run because neither can operate without repo-wide search.

Testing gaps:

• No CI step asserts that a resolutions pin is actually reflected in the resolved lockfile version, which is why a manifest-only bump reaches review looking complete.
• Nothing in the suite exercises the patched pattern-expansion behavior; coverage of this bump is limited to "install and build succeed", which is normal for a transitive security patch but means the forced cross-major override would surface only at runtime.

[github-actions]

<!-- deep-review -->

Deep Review

Degraded run — read this first. The multi-agent fan-out could not execute. In this environment every Bash invocation fails during sandbox setup (bwrap: Can't create file at /home/.mcp.json: Permission denied), including inside sub-agents, and no Grep/Glob tools exist. The skill's Stage 1 therefore could not compute git diff against the base SHA, and WebFetch was not permitted. Scope was reconstructed by reading package.json and yarn.lock directly with Read, and one reviewer persona was dispatched to adversarially verify the central claim. Findings below are grounded in quoted file content, but coverage is narrower than a normal review and no diff-derived scope check was possible.

🔴 P0/P1 -- must fix

• yarn.lock:12313 -- The lockfile still carries the stale descriptor "brace-expansion@npm:^2.1.2" at version: 2.1.2 while package.json:79 declares the resolution ^2.1.3, so no lockfile entry satisfies the new range and yarn install --immutable — Yarn 4's default whenever CI is set — aborts with YN0028.
  • Fix: Run yarn install at the repo root and commit the regenerated yarn.lock so the entry becomes "brace-expansion@npm:^2.1.3" at version: 2.1.3 with a fresh checksum.

That the ^2.1.2 key can only have come from the previous resolutions value is established rather than inferred: no dependent in the tree declares that range — minimatch variants declare ^1.1.7 (yarn.lock:21277, 21286), ^2.0.1 (21295), and ^5.0.2 (21304), none of which has a top-level entry. The same descriptor-rewrite pattern holds for other overrides, e.g. compression declares on-headers@~1.0.2 (yarn.lock:13412) yet the sole entry is "on-headers@npm:^1.1.0" (22335), matching package.json:81 verbatim.

One correction to note, since it changes what to worry about: this is not a case of the fix silently failing to apply at install time. 2.1.2 does not satisfy ^2.1.3, so a mutable install resolves 2.1.3 and dirties the tree rather than installing the old version. The defect is that the committed artifact is not installable in frozen mode, and every consumer that treats yarn.lock as the source of truth — SBOM generation, yarn npm audit, vendored-cache builds, dependency-state tooling — still reads 2.1.2.

🟡 P2 -- recommended

• .yarnrc.yml:5 -- npmMinimalAgeGate: 7d combined with npmPreapprovedPackages covering only @hyperdx/* and @clickhouse/* will filter out a brace-expansion@2.1.3 published inside the seven-day window, which is a plausible root cause for the lockfile hunk being absent since the Dependabot updater does not honor this gate.
  • Fix: Confirm brace-expansion@2.1.3 is older than seven days before regenerating, or temporarily add brace-expansion to npmPreapprovedPackages.

🔵 P3 nitpicks (1)

• package.json:79 -- The unscoped brace-expansion override collapses every major onto the 2.x line, force-upgrading minimatch@3.x's declared ^1.1.7 and force-downgrading minimatch@10.2.4's declared ^5.0.2; this is pre-existing on the base branch and unchanged by the version bump, but it is silently substituting a different major into minimatch 10.
  • Fix: Record the collapse as a deliberate decision, or scope the override to the specific dependents that require it.

---

Reviewers (1): correctness

Testing gaps:

• No lockfile/manifest consistency gate was observable in the tree — .github/workflows/ci.yml, ci.yaml, build.yaml, lint.yaml, and test.yaml all returned "file does not exist" and the directory could not be enumerated without Glob; a yarn install --immutable step would have failed this PR automatically.
• Nothing verifies that each of the 14 root resolutions keys has a matching yarn.lock entry keyed by that exact range, so all of them are exposed to the same silent drift.
• Publish-date verification for brace-expansion@2.1.3 was not possible (WebFetch denied), leaving the P2 age-gate interaction unconfirmed.

[teeohhem]

@dependabot recreate

[teeohhem]

@dependabot recreate

[github-actions]

Deep Review

The manifest pin and the committed lockfile disagree, which both breaks this PR's own required checks and leaves the intended version floor unenforced.

🔴 P0/P1 -- must fix

• package.json:79 -- The resolutions entry was raised to ^2.1.3, but yarn.lock was not regenerated: its only brace-expansion entry is still keyed brace-expansion@npm:^2.1.2 at version: 2.1.2, which cannot satisfy the new range.
  • Fix: Run yarn install to regenerate yarn.lock and commit it in the same change so the brace-expansion@npm:^2.1.3 descriptor and its matching checksum are present.
  • _{correctness, security, reliability, maintainability, testing}
• yarn.lock:12313 -- Because the lockfile is authoritative for every reproducible install, the intended floor is never enforced: installs resolve 2.1.2, and lockfile-reading scanners and SBOM generators keep reporting 2.1.2, so the change records a remediation the pinned artifact does not contain.
  • Fix: After regenerating, confirm the entry reads brace-expansion@npm:^2.1.3 with version: 2.1.3 before merging.
  • _{correctness, security}

Why this fails now: .github/workflows/main.yml:5-6 triggers on pull_request to main, and main.yml:44 runs yarn install --immutable. Yarn must rewrite the lockfile to honor the new range, so the install aborts with YN0028 before any build or test step. The same failure hits main.yml:67, main.yml:301, .github/workflows/knip.yml:29, and .github/actions/e2e-setup/action.yml:39. .yarnrc.yml has no enableImmutableInstalls: false escape hatch.

🟡 P2 -- recommended

• docker/hyperdx/Dockerfile:63 -- Image builds run yarn install --mode=skip-build with no --immutable and no CI variable, so they re-resolve the desynced graph and succeed, yielding a green docker-build check beside red main-CI checks and an image tree that no committed lockfile describes.
  • Fix: Add --immutable to the install steps at docker/hyperdx/Dockerfile:63, packages/api/Dockerfile:16, and packages/app/Dockerfile:14 so image builds fail loudly on lockfile drift.
  • _{security, reliability, testing}
• .yarnrc.yml:5 -- npmMinimalAgeGate: 7d applies to this package because npmPreapprovedPackages exempts only @hyperdx/* and @clickhouse/*, so if the pinned release is younger than the window, the lockfile regeneration this PR requires will itself be refused.
  • Fix: Confirm the pinned release has cleared the 7-day window before regenerating, and wait it out rather than widening the global age gate.
  • _{correctness, security, learnings-researcher}
• package.json:79 -- The unscoped resolutions key collapses every brace-expansion requester onto a single 2.x version, including minimatch@10.2.4, which declares brace-expansion: "npm:^5.0.2" at yarn.lock:21300-21307 — a three-major forced downgrade with no compatibility check.
  • Fix: Scope the override per major range so only the range that needs lifting is overridden, instead of one bare global key.
  • _{security, correctness, maintainability}
• .github/workflows/release.yml:75 -- YARN_ENABLE_IMMUTABLE_INSTALLS: false is scoped to the changesets/action@v1 step, but the job's own yarn install at line 57 runs earlier and is immutable via Yarn's CI auto-detection, so the opt-out does not cover the step that fails first.
  • Fix: Set the immutable-installs policy at the job level or explicitly on the line 57 step so the release job's install behavior is intentional.

🔵 P3 nitpicks (3)

• package.json:79 -- No changeset accompanies the change, while AGENTS.md:205-211 requires one for changes to a published package that affect behavior, and a transitive floor that ships inside @hyperdx/api and @hyperdx/app is arguably in scope.
  • Fix: Add a changeset, or confirm the team treats transitive override bumps as release-exempt internal tooling.
• package.json:70 -- The 14-entry resolutions block mixes vulnerability overrides with deliberate type-alignment pins and documents neither, so no maintainer can tell which entries become removable once upstream catches up.
  • Fix: Record each entry's purpose and removal criterion in an adjacent doc, since JSON cannot carry inline comments.
• .github/workflows/security-audit.yml:3 -- The vulnerability workflow runs only on a daily schedule and workflow_dispatch, so it is not a pre-merge gate and would surface a missed remediation up to a day after merge.
  • Fix: Treat the --immutable install jobs, not this workflow, as the pre-merge guard against dependency drift.

---

Reviewers (7): correctness, security, reliability, maintainability, testing, project-standards, learnings-researcher.

_{Verification note: git was unavailable in this environment, so the changed-file list could not be enumerated directly. Every finding above is anchored to file contents read directly from the checked-out tree.}

Testing gaps:

• No pre-merge check asserts that resolutions entries are reflected in yarn.lock; a yarn install --mode=update-lockfile && git diff --exit-code yarn.lock preflight would catch this class cheaply and with a targeted signal instead of five jobs failing at "Install root dependencies".
• Nothing asserts that the resolved version of an overridden dependency meets the intended floor — --immutable proves only that the lockfile is unchanged, not that the override was honored.
• Docker image builds have no dependency verification at all, so the path that produces release artifacts lacks any equivalent of CI's --immutable gate.
• No test exercises minimatch 10.x against the force-downgraded brace-expansion 2.x, so a brace-expansion semantics change would surface only at runtime.