-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: process sourcemaps for stack traces from globalSetup
files
#7101
base: main
Are you sure you want to change the base?
fix: process sourcemaps for stack traces from globalSetup
files
#7101
Conversation
Possibly related to vitest-dev#5605 but not sure
✅ Deploy Preview for vitest-dev ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
@vitest/browser
@vitest/coverage-istanbul
@vitest/expect
@vitest/coverage-v8
@vitest/mocker
@vitest/pretty-format
@vitest/runner
@vitest/snapshot
@vitest/spy
@vitest/ui
@vitest/utils
vite-node
vitest
@vitest/web-worker
@vitest/ws-client
commit: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR 👋
I had a few concerns about this, but while thinking about it, they might be actually a non issue. Let me write this down.
The first one is what happens when multiple projects have globalSetup
and do installSourcemapsSupport
. This appears to be fine because Vite-node supports registering multiple handlers properly for each installSourcemapsSupport
call. I was just testing this with pkg.pr.new in my repro and error stack is working after this PR https://github.com/hi-ogawa/reproductions/tree/main/vitest-global-setup-error-stack
The 2nd one is mostly about our internal tests. We often runs vitest inside vitest via runVitest
of test-utils
and I'm not sure whether installSourcemapsSupport
referenced from inside and outside are the same thing. I'll check this later.
For the tests, there is a test asserting global setup error stack, which just happens to pass since the code is plain js (I found this while doing #7096):
expect(stderr).toContain('setup-unhandled-rejections.ts:2:42') |
Can you make
setup-unhandled-rejections.ts
more complicated and see if error position maps correctly?
Description
When a
globalSetup
file (or a module imported as a result of aglobalSetup
file's execution) has an error at runtime, the sourcemaps were not being used, because globalSetup files are executed withnode:vm
(which doesn't read sourcemaps).In my manual testing, calling
installSourcemapsSupport
before loading the globalSetup files will fix the issue.Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
pnpm-lock.yaml
unless you introduce a new test example.Tests
pnpm test:ci
.Documentation
pnpm run docs
command.Changesets
feat:
,fix:
,perf:
,docs:
, orchore:
.