[robobun]

Problem

• bun test -t 'mixedcase target' does not run a test named MixedCase Target. It prints error: regex "mixedcase target" matched 0 tests. Jest runs that test.
• The cause is RegexFlags::None where the pattern is compiled (src/runtime/cli/Arguments.rs:1941). jest-circus 30.5.2 compiles new RegExp(testNamePattern, 'i').

Fix

• Compile the pattern with RegexFlags::IgnoreCase.
• A (?-i:...) group in the pattern matches case again.
• --help, the shell completions and the docs now say that it ignores case.
• Verified: test/cli/test/bun-test.test.ts, test -t matches test names case-insensitively. Release 1.4.3-canary.1 fails it and this branch passes it.

Background

• -t / --test-name-pattern filters tests by name. Bun matches the regex against the test name prefixed with the labels of its describe blocks.
• Bun compiles the pattern once per process, and only when the flag is present.
• Split from spyOn: install and restore through one writer that throws when the object refuses #34976. No other place fits this fix: the flag is a constant on one line.

Downsides

• This changes a shipped default, and a maintainer must decide that it is wanted. An existing filter now selects more tests: -t API also runs a test named capital letters. No flag restores the old match. A user rewrites the pattern as -t '(?-i:API)'.
• The VS Code extension builds ^ ?name$ patterns from exact test names (buildTestNamePattern in packages/bun-vscode). "Run this test" now also runs a test whose name differs only in case. This PR does not change the extension.
• With -t, each name match folds case: +156 instructions (8,230 to 8,386) for a 68-character name with no match. Without -t, Bun compiles no pattern.

Notes

• Source of the ask: item (c) of a test-runner audit against jest 30.4.1.

• The alternative to the default change is an opt-in flag. I did not add one, because the ask was Jest's behavior by default and a new flag is new public surface.

• Vitest and Mocha's --grep match case. Bun's --grep alias now differs from Mocha's.

• The extension could wrap its pattern in (?-i:...). I did not do that here: the extension runs the bun that the user has installed, and I have not checked which released versions accept a modifier group.

• Cost of the i flag, in instructions for one call of Yarr__RegularExpression__matches with -t 'mixedcase target'. Release build of main (af5743d). gdb sets the flags argument of Yarr__RegularExpression__init to 0 or to IgnoreCase, then single-steps each call. 3 runs give the same counts. perf and valgrind are not installed here.

  name that Bun matches	case-sensitive	ignore case
  suite mixedcase target	1,909, match	1,912, match
  suite MixedCase Target	2,294, no match	1,862, match
  suite another test	1,794, no match	1,803, no match
  a 63-character name	7,729, no match	7,868, no match
  a 68-character name	8,230, no match	8,386, no match

• bun-test.test.ts on the local debug build: 103 pass, 6 todo, 2 fail. The two failures are instances of a class nested too deeply to print are a RangeError and the data of events nested too deeply to print are a RangeError. Both time out after 5000ms, and neither passes -t.

[robobun]

^{Updated 11:36 PM PT - Oct 15th, 2026}

❌ @robobun, your commit f20d19d has 2 failures in Build #126380 (All Failures):

• test/cli/install/bun-install-windows-rename-retry.test.ts - code 1 on 🪟 11 aarch64
• step failed outside runner - exit 1 on 🍎 any aarch64 - test-bun

---

🧪   To try this PR locally:

bunx bun-pr 45447

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

bun-45447 --bun

[robobun]

How to reproduce on a release build:

• Put test("MixedCase Target", () => {}) in case.test.ts.
• Run bun test case.test.ts -t 'mixedcase target'.
• Release 1.4.3-canary.1 prints error: regex "mixedcase target" matched 0 tests. This branch runs the test.

This PR is the -t half of #34976, split out so that the spyOn rework there does not block it.

CI at f20d19d (build 126380) is finished: 179 jobs passed and 2 failed. Neither failure is in code that this PR changes, and test/cli/test/bun-test.test.ts passed on every lane that ran it:

• test/cli/install/bun-install-windows-rename-retry.test.ts on Windows 11 aarch64. The same test is red on spyOn: install and restore through one writer that throws when the object refuses #34976 at the same base.
• The macOS aarch64 test job stopped before it ran a test: buildkite-agent artifact download timed out after 120s for step 'darwin-aarch64-build-bun'. A retry of that job runs the tests on that lane.

One decision is open for a maintainer: is the case-insensitive match wanted as the default? The PR body lists who it affects.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository: oven-sh/bun/.coderabbit.yaml
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 518bf3e1-b0cf-49df-9095-4707e05e93da

📥 Commits

Reviewing files that changed from the base of the PR and between 984a055 and 6218c37.

📒 Files selected for processing: 4

• completions/bun-cli.json
• completions/bun.zsh
• src/runtime/cli/Arguments.rs
• test/cli/test/bun-test.test.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 3 remain after this review.

Walkthrough

The --test-name-pattern option now compiles regular expressions for case-insensitive matching. CLI tests verify the default behavior and the (?-i:...) group for case-sensitive matching. Help text, completions, and documentation describe the behavior.

Changes

Test-name matching

Layer / File(s)	Summary
Pattern matching behavior src/runtime/cli/Arguments.rs, test/cli/test/bun-test.test.ts, docs/snippets/cli/test.mdx, docs/test/discovery.mdx, completions/bun-cli.json, completions/bun.zsh	The CLI compiles test-name patterns with case-insensitive matching. Tests cover mixed-case names and scoped case-sensitive matching. Help text, completions, and documentation describe these behaviors.

Suggested reviewers: jarred-sumner

Priority: ⬇️ Low

Merge Risk: ⚪ Minimal · up to 6218c

Case-insensitive test-name matching and its case-sensitive escape behave as documented. No merge-blocking issue was identified.

Pre-merge checks: 4

Check name	Status	Explanation
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Title check		The title clearly and concisely describes the main change: case-insensitive matching for bun test name patterns.
Description check		The description explains the problem, implementation, behavior changes, trade-offs, and verification results. It covers the required information, although it uses Problem and Fix headings instead of t…

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[claude]

Beyond the inline findings, I also checked for sibling sites compiling the name pattern: RegularExpression::init at src/runtime/cli/Arguments.rs:1939 is the only compile of -t, and parallel workers receive the raw test_filter_pattern (src/runtime/cli/test/parallel/runner.rs:315) and re-parse it through the same path, so they inherit the same flag — no bunfig or programmatic site needs a matching change.

Extended reasoning...

The diff is a one-flag change (RegexFlags::None to IgnoreCase) in the -t/--test-name-pattern parser, plus two doc edits and one new test; it touches no security-sensitive surface. Inline findings already cover the default-behavior change for existing users and the one-directional (?-i:...) assertion, so a human should weigh the compat decision; this body only records the sibling-site check that was ruled out.

Findings marked 🟡 are optional suggestions and need no follow-up push.

[claude]

I re-reviewed after the latest commit and found no bugs; the help text, completions, and the positive (?-i:...) test variant now cover what I raised earlier. Since this flips the default selection behavior of a shipped flag (-t/--test-name-pattern/--grep) for every existing caller, a maintainer should still decide whether that break is acceptable.

What was reviewed:

• Flag plumbing: IgnoreCase = 1 << 2 in src/jsc/RegularExpression.rs is passed verbatim into OptionSet<Yarr::Flags> in src/jsc/bindings/RegularExpression.cpp, and this is the only compile site; test_command.rs and the parallel runner's -t forwarding both consume it.
• Existing suite: grepped every -t/--test-name-pattern use in test/ — none asserts case-sensitive filtering, so no stale assertions.
• One consumer worth a maintainer's eye: the VS Code extension (packages/bun-vscode/src/features/tests/bun-test-controller.ts, buildTestNamePattern) builds anchored ^ ?name$ patterns from exact test names and does not wrap them in (?-i:...), so "Run this test" will now also run a sibling whose name differs only by case.

Extended reasoning...

The change is a one-constant edit in src/runtime/cli/Arguments.rs (RegexFlags::None to RegexFlags::IgnoreCase) plus help text, shell completions, two docs pages, and one new test in test/cli/test/bun-test.test.ts. It touches no security-sensitive surface; the regex is compiled from a CLI argument with the same JSC engine as before. The follow-up commit addressed both prior inline comments, the flag bit maps correctly to Yarr, and no existing test depends on the old case-sensitive behavior. Deferring because the PR changes the default behavior of a shipped user-facing flag (including the Mocha-style --grep alias) with no opt-in, which is a product decision for a maintainer rather than a correctness question.

[robobun]

Thank you. I added the VS Code extension to Downsides in the PR body: buildTestNamePattern builds ^ ?name$ from exact names, so "Run this test" now also runs a test whose name differs only in case. I did not change the extension in this PR. The default change itself waits for a maintainer's decision.