vitest 0.34.3 - incorrect/missing stack traces with workspaces

[robertjpayne]

Describe the bug

I've got a mono repo setup, with some aliases and other configs and vitest is failing to provide stack traces (or if it does provide them they are not being translated back to the source maps).

I've attached a simple reproduction (I'm using Remix) via StackBlitz.

In my investigations I came across packages/vitest/src/node/error.ts:43:

  const parserOptions: StackTraceParserOptions = {
    // only browser stack traces require remapping
    getSourceMap: file => project.getBrowserSourceMapModuleById(file),
  }

If I changed this to be project.getSourceMapModuleById(file) it seemed to work?

Reproduction

https://stackblitz.com/edit/vitest-dev-vitest-b8e5f1?file=package.json

System Info

System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 16.20.0 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 9.4.2 - /usr/local/bin/npm
    pnpm: 8.6.10 - /usr/local/bin/pnpm
  npmPackages:
    @vitest/ui: latest => 0.34.3 
    vite: latest => 4.4.9 
    vitest: latest => 0.34.3

Used Package Manager

npm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[stackblitz]

Start a new pull request in StackBlitz Codeflow.

• vitest-dev-vitest-b8e5f1 (Open reproduction)

[sheremet-va]

As I answered in PR, the function should only be defined for browser for now because they are patched before that when running in node, and should already be resolved.

[robertjpayne]

@sheremet-va intersting -- in my reproduction case above that isn't the case, there is some source mapping that isn't occurring that should be (and is if it's not limited to run for the browser only).

It might be something to do with remix's installGlobals() though if there's a reliance on node internals

[sheremet-va]

in my reproduction case above that isn't the case

Yes, in your case there is something that prevents it, so it's bug that needs investigating. If you want, you can look into this and why it doesn't return correct source map in your case:

vitest/packages/vite-node/src/source-map.ts

Line 61 in bf83936

export function installSourcemapsSupport(options: InstallSourceMapSupportOptions) {

[robertjpayne]

@sheremet-va Righto so debugging that a bit further:

1. For this example project the installSourcemapsSupport function is called and the install function is called but the retrieveSourceMap function never is used.

2. Looking at entry.js in the dist and debugging it, my test files are in the module cache that the getSourceMap things use.

I'll keep digging…

[robertjpayne]

Tracked it down, Remix uses source-map-support as well and importing @remix-run/node does:

import sourceMapSupport from "source-map-support";

sourceMapSupport.install();

I don't know enough about what that might do but I'd argue that is why things are getting mangled.

[robertjpayne]

Ok so I don't even know if this is really "fixable". There is Error.prepareStackTrace which is called by V8 and is what vitest and "source-map-support" both set.

Vitest does this on process launch which means further invocations of it wipe out what Vitest is trying to do.

[sheremet-va]

Yeah, remix shouldn't call it for Vitest.

[robertjpayne]

@sheremet-va Yea I'll open a ticket on Remix side, this is more their issue as there is no way to "disable" it and it should allow an override to the auto installing of it.