If the program being tested leverages prepareStackTrace then line numbers for a failed test are incorrect

[NorthernMan54]

Recently identified this when testing plugins for the package homebridge, and found that when a test fails the source map shown is at an incorrect location.

npm run test
npm warn config global-style This option has been deprecated in favor of `--install-strategy=shallow`

> vitest-source-map-support-repro@1.0.0 test
> vitest run

`esbuild` option is set to false, but `oxc` option was not set to false. `esbuild: false` does not have effect any more. If you want to disable the default transformation, which is now handled by Oxc, please set `oxc: false` instead.

 RUN  v4.1.7 

 ❯ source-map-support.test.ts (3 tests | 1 failed) 5ms
   ✓ source-map-support + vitest (2)
     ✓ error.stack is a string after source-map-support/register 2ms
     ✓ stack trace contains expected string content 0ms
   ❯ line numbers (1)
     × stack trace has correct line numbers - Line 28 s/b 25 2ms

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ Failed Tests 1 ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

 FAIL  source-map-support.test.ts > line numbers > stack trace has correct line numbers - Line 28 s/b 25
AssertionError: expected 1 to be 2 // Object.is equality

- Expected
+ Received

- 2
+ 1

 ❯ source-map-support.test.ts:28:45
     27| });
     28|
     29| // To test the bug, run with the default Vitest config which uses the threads p…
       |                                            ^

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[1/1]⎯


 Test Files  1 failed (1)
      Tests  1 failed | 2 passed (3)
   Start at  22:11:12
   Duration  150ms (transform 41ms, setup 0ms, import 54ms, tests 5ms, environment 0ms)

And after some intense digging found that the issue is triggered by our usage of the package source-map-support, and its internal usage of prepareStackTrace.

We dig a far bit of digging and could not find a workaround for the issue, and was wondering if the community had anything.

package.json

{
  "name": "vitest-source-map-support-repro",
  "version": "1.0.0",
  "type": "module",
  "scripts": {
    "test": "vitest run"
  },
  "devDependencies": {
    "@swc/core": "^1.15.40",
    "source-map-support": "^0.5.21",
    "typescript": "^5.9.3",
    "unplugin-swc": "^1.5.9",
    "vitest": "^4.1.7"
  }
}

Test

import { describe, test, expect } from 'vitest';
import 'source-map-support/register.js';

// prepareStackTrace is used by both source-map-support and Vitest's module runner and can conflict causing the source map support to indicate the incorrect line numbers

describe('source-map-support + vitest', () => {
  test('error.stack is a string after source-map-support/register', () => {
    const err = new Error('test');
    // Fails with the bug: err.stack is a CallSite[] array, not a string
    expect(typeof err.stack).toBe('string');
    expect(() => err.stack!.split('\n')).not.toThrow();
  });

  test('stack trace contains expected string content', () => {
    const err = new Error('hello');
    // Also fails if .stack is an array — array.includes() !== string.includes()
    expect(err.stack).toContain('hello');
  });
});

describe('line numbers', () => {
  test('stack trace has correct line numbers - Line 28 s/b 25', () => {
    expect(true).toBeTruthy();

    expect(1).toBe(2); // Line 25
  });
});

// To test the bug, run with the default Vitest config

Environment

 System:
    OS: macOS 26.5
    CPU: (8) arm64 Apple M1 Pro
    Memory: 159.66 MB / 16.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 24.11.1 - /usr/local/bin/node
    npm: 11.6.2 - /usr/local/bin/npm
  Browsers:
    Firefox: 87.0
    Safari: 26.5
  npmPackages:
    vitest: ^4.1.7 => 4.1.7 

[chrisjcthomas]

source-map-support/register is very likely the problem here. It patches the process-wide Error.prepareStackTrace, and Vitest also relies on stack preparation/source-map handling for its failure output. Those two hooks are not really composable because only one Error.prepareStackTrace function owns the final CallSite[] -> string conversion at a time.

So I would not register source-map-support inside Vitest unless you absolutely have to. Vitest already remaps stack traces for transformed test files.

Practical options I would try, in this order:

1. Remove this from tests/setup code:

import 'source-map-support/register.js'

2. If the application package registers it at module import time, mock it in tests so it does not patch Error.prepareStackTrace:

vi.mock('source-map-support/register.js', () => ({}))

or mock the module that imports it before importing the code under test.

3. If you need source maps for plain Node execution outside Vitest, prefer enabling them only in the app/CLI entrypoint, not in shared library modules that are imported by tests.

4. If you are trying to debug untransformed Node stack traces, try Node's native source maps (NODE_OPTIONS=--enable-source-maps) outside Vitest rather than layering source-map-support on top of Vitest's runner.

I do not think there is a reliable local fix that lets both Vitest and source-map-support own prepareStackTrace at the same time. The most stable workaround is to keep source-map-support/register out of the Vitest process.

[NorthernMan54]

@chrisjcthomas Am thinking I will need to go back into the source for the modules that are doing the import, and change it to a conditional import when running running outside of vitest. Looking at process.env, I can see

TEST: 'true', VITEST: 'true', NODE_ENV: 'test',

So a simple test to see if your running VITEST, should work.

Thanks very much