Files
bun.sh/docs/runtime/bunfig.md
robobun e58a4a7282 feat: add concurrent-test-glob option to bunfig.toml for selective concurrent test execution (#22898)
## Summary

Adds a new `concurrentTestGlob` configuration option to bunfig.toml that
allows test files matching a glob pattern to automatically run with
concurrent test execution enabled. This provides granular control over
which tests run concurrently without modifying test files or using the
global `--concurrent` flag.

## Problem

Currently, enabling concurrent test execution in Bun requires either:
1. Using the `--concurrent` flag (affects ALL tests)
2. Manually adding `test.concurrent()` to individual test functions
(requires modifying test files)

This creates challenges for:
- Large codebases wanting to gradually migrate to concurrent testing
- Projects with mixed test types (unit tests that need isolation vs
integration tests that can run in parallel)
- CI/CD pipelines that want to optimize test execution without code
changes

## Solution

This PR introduces a `concurrentTestGlob` option in bunfig.toml that
automatically enables concurrent execution for test files matching a
specified glob pattern:

```toml
[test]
concurrentTestGlob = "**/concurrent-*.test.ts"
```

### Key Features
-  Non-breaking: Completely opt-in via configuration
-  Flexible: Use glob patterns to target specific test files or
directories
-  Override-friendly: `--concurrent` flag still forces all tests to run
concurrently
-  Zero code changes: No need to modify existing test files

## Implementation Details

### Code Changes
1. Added `concurrent_test_glob` field to `TestOptions` struct
(`src/cli.zig`)
2. Added parsing for `concurrentTestGlob` from bunfig.toml
(`src/bunfig.zig`)
3. Added `concurrent_test_glob` field to `TestRunner`
(`src/bun.js/test/jest.zig`)
4. Implemented `shouldFileRunConcurrently()` method that checks file
paths against the glob pattern
5. Updated test execution logic to apply concurrent mode based on glob
matching (`src/bun.js/test/ScopeFunctions.zig`)

### How It Works
- When a test file is loaded, its path is checked against the configured
glob pattern
- If it matches, all tests in that file run concurrently (as if
`--concurrent` was passed)
- Files not matching the pattern run sequentially as normal
- The `--concurrent` CLI flag overrides this behavior when specified

## Usage Examples

### Basic Usage
```toml
# bunfig.toml
[test]
concurrentTestGlob = "**/integration/*.test.ts"
```

### Multiple Patterns
```toml
[test]
concurrentTestGlob = [
  "**/integration/*.test.ts",
  "**/e2e/*.test.ts", 
  "**/concurrent-*.test.ts"
]
```

### Migration Strategy
Teams can gradually migrate to concurrent testing:
1. Start with integration tests: `"**/integration/*.test.ts"`
2. Add stable unit tests: `"**/fast-*.test.ts"`
3. Eventually migrate most tests except those requiring isolation

## Testing

Added comprehensive test coverage in
`test/cli/test/concurrent-test-glob.test.ts`:
-  Tests matching glob patterns run concurrently (verified via
execution order logging)
-  Tests not matching patterns run sequentially (verified via shared
state and execution order)
-  `--concurrent` flag properly overrides the glob setting
- Tests use file system logging to deterministically verify concurrent
vs sequential execution

## Documentation

Complete documentation added:
- `docs/runtime/bunfig.md` - Configuration reference
- `docs/test/configuration.md` - Test configuration details
- `docs/test/examples/concurrent-test-glob.md` - Comprehensive example
with migration guide

## Performance Considerations

- Glob matching happens once per test file during loading
- Uses Bun's existing `glob.match()` implementation
- Minimal overhead: simple string pattern matching
- Future optimization: Could cache match results per file path

## Breaking Changes

None. This is a fully backward-compatible, opt-in feature.

## Checklist

- [x] Implementation complete and building
- [x] Tests passing
- [x] Documentation updated
- [x] No breaking changes
- [x] Follows existing code patterns

## Related Issues

This addresses common requests for more granular control over concurrent
test execution, particularly for large codebases migrating from other
test runners.

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

---------

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
2025-09-23 23:01:15 -07:00

17 KiB

Bun's behavior can be configured using its configuration file, bunfig.toml.

In general, Bun relies on pre-existing configuration files like package.json and tsconfig.json to configure its behavior. bunfig.toml is only necessary for configuring Bun-specific things. This file is optional, and Bun will work out of the box without it.

Global vs. local

In general, it's recommended to add a bunfig.toml file to your project root, alongside your package.json.

To configure Bun globally, you can also create a .bunfig.toml file at one of the following paths:

  • $HOME/.bunfig.toml
  • $XDG_CONFIG_HOME/.bunfig.toml

If both a global and local bunfig are detected, the results are shallow-merged, with local overriding global. CLI flags will override bunfig setting where applicable.

Runtime

Bun's runtime behavior is configured using top-level fields in the bunfig.toml file.

preload

An array of scripts/plugins to execute before running a file or script.

# scripts to run before `bun run`-ing a file or script
# register plugins by adding them to this list
preload = ["./preload.ts"]

jsx

Configure how Bun handles JSX. You can also set these fields in the compilerOptions of your tsconfig.json, but they are supported here as well for non-TypeScript projects.

jsx = "react"
jsxFactory = "h"
jsxFragment = "Fragment"
jsxImportSource = "react"

Refer to the tsconfig docs for more information on these fields.

smol

Enable smol mode. This reduces memory usage at the cost of performance.

# Reduce memory usage at the cost of performance
smol = true

logLevel

Set the log level. This can be one of "debug", "warn", or "error".

logLevel = "debug" # "debug" | "warn" | "error"

define

The define field allows you to replace certain global identifiers with constant expressions. Bun will replace any usage of the identifier with the expression. The expression should be a JSON string.

[define]
# Replace any usage of "process.env.bagel" with the string `lox`.
# The values are parsed as JSON, except single-quoted strings are supported and `'undefined'` becomes `undefined` in JS.
# This will probably change in a future release to be just regular TOML instead. It is a holdover from the CLI argument parsing.
"process.env.bagel" = "'lox'"

loader

Configure how Bun maps file extensions to loaders. This is useful for loading files that aren't natively supported by Bun.

[loader]
# when a .bagel file is imported, treat it like a tsx file
".bagel" = "tsx"

Bun supports the following loaders:

  • jsx
  • js
  • ts
  • tsx
  • css
  • file
  • json
  • toml
  • yaml
  • wasm
  • napi
  • base64
  • dataurl
  • text

telemetry

The telemetry field permit to enable/disable the analytics records. Bun records bundle timings (so we can answer with data, "is Bun getting faster?") and feature usage (e.g., "are people actually using macros?"). The request body size is about 60 bytes, so it's not a lot of data. By default the telemetry is enabled. Equivalent of DO_NOT_TRACK env variable.

telemetry = false

console

Configure console output behavior.

console.depth

Set the default depth for console.log() object inspection. Default 2.

[console]
depth = 3

This controls how deeply nested objects are displayed in console output. Higher values show more nested properties but may produce verbose output for complex objects. This setting can be overridden by the --console-depth CLI flag.

Test runner

The test runner is configured under the [test] section of your bunfig.toml.

[test]
# configuration goes here

test.root

The root directory to run tests from. Default ..

[test]
root = "./__tests__"

test.preload

Same as the top-level preload field, but only applies to bun test.

[test]
preload = ["./setup.ts"]

test.smol

Same as the top-level smol field, but only applies to bun test.

[test]
smol = true

test.coverage

Enables coverage reporting. Default false. Use --coverage to override.

[test]
coverage = false

test.coverageThreshold

To specify a coverage threshold. By default, no threshold is set. If your test suite does not meet or exceed this threshold, bun test will exit with a non-zero exit code to indicate the failure.

[test]

# to require 90% line-level and function-level coverage
coverageThreshold = 0.9

Different thresholds can be specified for line-wise, function-wise, and statement-wise coverage.

[test]
coverageThreshold = { line = 0.7, function = 0.8, statement = 0.9 }

test.coverageSkipTestFiles

Whether to skip test files when computing coverage statistics. Default false.

[test]
coverageSkipTestFiles = false

test.coveragePathIgnorePatterns

Exclude specific files or file patterns from coverage reports using glob patterns. Can be a single string pattern or an array of patterns.

[test]
# Single pattern
coveragePathIgnorePatterns = "**/*.spec.ts"

# Multiple patterns
coveragePathIgnorePatterns = [
  "**/*.spec.ts",
  "**/*.test.ts",
  "src/utils/**",
  "*.config.js"
]

test.coverageReporter

By default, coverage reports will be printed to the console. For persistent code coverage reports in CI environments and for other tools use lcov.

[test]
coverageReporter  = ["text", "lcov"]  # default ["text"]

test.coverageDir

Set path where coverage reports will be saved. Please notice, that it works only for persistent coverageReporter like lcov.

[test]
coverageDir = "path/to/somewhere"  # default "coverage"

test.concurrentTestGlob

Specify a glob pattern to automatically run matching test files with concurrent test execution enabled. Test files matching this pattern will behave as if the --concurrent flag was passed, running all tests within those files concurrently.

[test]
concurrentTestGlob = "**/concurrent-*.test.ts"

This is useful for:

  • Gradually migrating test suites to concurrent execution
  • Running integration tests concurrently while keeping unit tests sequential
  • Separating fast concurrent tests from tests that require sequential execution

The --concurrent CLI flag will override this setting when specified.

Package manager

Package management is a complex issue; to support a range of use cases, the behavior of bun install can be configured under the [install] section.

[install]
# configuration here

install.optional

Whether to install optional dependencies. Default true.

[install]
optional = true

install.dev

Whether to install development dependencies. Default true.

[install]
dev = true

install.peer

Whether to install peer dependencies. Default true.

[install]
peer = true

install.production

Whether bun install will run in "production mode". Default false.

In production mode, "devDependencies" are not installed. You can use --production in the CLI to override this setting.

[install]
production = false

install.exact

Whether to set an exact version in package.json. Default false.

By default Bun uses caret ranges; if the latest version of a package is 2.4.1, the version range in your package.json will be ^2.4.1. This indicates that any version from 2.4.1 up to (but not including) 3.0.0 is acceptable.

[install]
exact = false

install.saveTextLockfile

If false, generate a binary bun.lockb instead of a text-based bun.lock file when running bun install and no lockfile is present.

Default true (since Bun v1.2).

[install]
saveTextLockfile = false

install.auto

To configure Bun's package auto-install behavior. Default "auto" — when no node_modules folder is found, Bun will automatically install dependencies on the fly during execution.

[install]
auto = "auto"

Valid values are:

{% table %}

  • Value
  • Description

  • "auto"
  • Resolve modules from local node_modules if it exists. Otherwise, auto-install dependencies on the fly.

  • "force"
  • Always auto-install dependencies, even if node_modules exists.

  • "disable"
  • Never auto-install dependencies.

  • "fallback"
  • Check local node_modules first, then auto-install any packages that aren't found. You can enable this from the CLI with bun -i.

{% /table %}

install.frozenLockfile

When true, bun install will not update bun.lock. Default false. If package.json and the existing bun.lock are not in agreement, this will error.

[install]
frozenLockfile = false

install.dryRun

Whether bun install will actually install dependencies. Default false. When true, it's equivalent to setting --dry-run on all bun install commands.

[install]
dryRun = false

install.globalDir

To configure the directory where Bun puts globally installed packages.

Environment variable: BUN_INSTALL_GLOBAL_DIR

[install]
# where `bun install --global` installs packages
globalDir = "~/.bun/install/global"

install.globalBinDir

To configure the directory where Bun installs globally installed binaries and CLIs.

Environment variable: BUN_INSTALL_BIN

# where globally-installed package bins are linked
globalBinDir = "~/.bun/bin"

install.registry

The default registry is https://registry.npmjs.org/. This can be globally configured in bunfig.toml:

[install]
# set default registry as a string
registry = "https://registry.npmjs.org"
# set a token
registry = { url = "https://registry.npmjs.org", token = "123456" }
# set a username/password
registry = "https://username:password@registry.npmjs.org"

install.linkWorkspacePackages

To configure how workspace packages are linked, use the install.linkWorkspacePackages option.

Whether to link workspace packages from the monorepo root to their respective node_modules directories. Default true.

[install]
linkWorkspacePackages = true

install.scopes

To configure a registry for a particular scope (e.g. @myorg/<package>) use install.scopes. You can reference environment variables with $variable notation.

[install.scopes]
# registry as string
myorg = "https://username:password@registry.myorg.com/"

# registry with username/password
# you can reference environment variables
myorg = { username = "myusername", password = "$npm_password", url = "https://registry.myorg.com/" }

# registry with token
myorg = { token = "$npm_token", url = "https://registry.myorg.com/" }

install.ca and install.cafile

To configure a CA certificate, use install.ca or install.cafile to specify a path to a CA certificate file.

[install]
# The CA certificate as a string
ca = "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----"

# A path to a CA certificate file. The file can contain multiple certificates.
cafile = "path/to/cafile"

install.cache

To configure the cache behavior:

[install.cache]

# the directory to use for the cache
dir = "~/.bun/install/cache"

# when true, don't load from the global cache.
# Bun may still write to node_modules/.cache
disable = false

# when true, always resolve the latest versions from the registry
disableManifest = false

install.lockfile

To configure lockfile behavior, use the install.lockfile section.

Whether to generate a lockfile on bun install. Default true.

[install.lockfile]
save = true

Whether to generate a non-Bun lockfile alongside bun.lock. (A bun.lock will always be created.) Currently "yarn" is the only supported value.

[install.lockfile]
print = "yarn"

install.security.scanner

Configure a security scanner to scan packages for vulnerabilities before installation.

First, install a security scanner from npm:

$ bun add -d @acme/bun-security-scanner

Then configure it in your bunfig.toml:

[install.security]
scanner = "@acme/bun-security-scanner"

When a security scanner is configured:

  • Auto-install is automatically disabled for security
  • Packages are scanned before installation
  • Installation is cancelled if fatal issues are found
  • Security warnings are displayed during installation

Learn more about using and writing security scanners.

install.linker

Configure the default linker strategy. Default "hoisted".

For complete documentation refer to Package manager > Isolated installs.

[install]
linker = "hoisted"

Valid values are:

{% table %}

  • Value
  • Description

  • "hoisted"
  • Link dependencies in a shared node_modules directory.

  • "isolated"
  • Link dependencies inside each package installation.

{% /table %}

bun run

The bun run command can be configured under the [run] section. These apply to the bun run command and the bun command when running a file or executable or script.

Currently, bunfig.toml isn't always automatically loaded for bun run in a local project (it does check for a global bunfig.toml), so you might still need to pass -c or -c=bunfig.toml to use these settings.

run.shell - use the system shell or Bun's shell

The shell to use when running package.json scripts via bun run or bun. On Windows, this defaults to "bun" and on other platforms it defaults to "system".

To always use the system shell instead of Bun's shell (default behavior unless Windows):

[run]
# default outside of Windows
shell = "system"

To always use Bun's shell instead of the system shell:

[run]
# default on Windows
shell = "bun"

run.bun - auto alias node to bun

When true, this prepends $PATH with a node symlink that points to the bun binary for all scripts or executables invoked by bun run or bun.

This means that if you have a script that runs node, it will actually run bun instead, without needing to change your script. This works recursively, so if your script runs another script that runs node, it will also run bun instead. This applies to shebangs as well, so if you have a script with a shebang that points to node, it will actually run bun instead.

By default, this is enabled if node is not already in your $PATH.

[run]
# equivalent to `bun --bun` for all `bun run` commands
bun = true

You can test this by running:

$ bun --bun which node # /path/to/bun
$ bun which node # /path/to/node

This option is equivalent to prefixing all bun run commands with --bun:

bun --bun run dev
bun --bun dev
bun run --bun dev

If set to false, this will disable the node symlink.

run.silent - suppress reporting the command being run

When true, suppresses the output of the command being run by bun run or bun.

[run]
silent = true

Without this option, the command being run will be printed to the console:

$ bun run dev
> $ echo "Running \"dev\"..."
Running "dev"...

With this option, the command being run will not be printed to the console:

$ bun run dev
Running "dev"...

This is equivalent to passing --silent to all bun run commands:

bun --silent run dev
bun --silent dev
bun run --silent dev