Skip to content

Debugging and Coverage Instrumentation for Child Processes (Bun.spawn) #17867

Open
@bitjson

Description

@bitjson

What is the problem this feature would solve?

Currently, when writing end-to-end tests for code that spawns new Bun processes (e.g., using Bun.spawn), the built-in coverage tool does not capture coverage data for code running in those child processes. This makes it difficult to track or ensure comprehensive test coverage in real-world scenarios where applications and CLI utilities run as separate processes.

Additionally, debugging breakpoints set on lines evaluated by the child processes don't pause evaluation (e.g. in the VSCode extension's Debug File feature).

What is the feature you are proposing to solve the problem?

Add support for debugging, instrumenting, and collecting code coverage across multiple Bun processes during test runs. Ideally, this would involve Bun automatically propagating coverage instrumentation to any child processes spawned within a test file, then aggregating the resulting coverage data.

Key points:

  • Allow bun test --coverage to detect when a test spawns a Bun subprocess, enabling coverage instrumentation in the child process.
  • Merge coverage results from the child processes back into the main coverage report automatically.
  • Provide an environment variable or configuration setting so advanced users can customize or disable coverage propagation for child processes if needed. (In Node.js, this is NODE_V8_COVERAGE.)

What alternatives have you considered?

  1. Refactoring to a single process: Restructuring code so that test logic and CLI code run in the same Bun process can solve coverage gaps, but it isn’t always practical. CLI programs often need genuine process isolation to properly simulate various environments.

  2. Using third-party coverage tools: Tools like NYC or c8 can instrument code in a child process, but that requires extra setup, merges, and tooling outside Bun’s built-in test/coverage system. This increases complexity and maintenance burden.

  3. Manual instrumentation or custom scripts: Developers can manually track coverage in each subprocess and merge the results, but this is complicated and not user-friendly. Automatic support from Bun would be far more convenient.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bun:spawnbun:testSomething related to the `bun test` runnerenhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions