Skip to content
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

Wrong stacktrace and broken debugging with esbuild.sourcemap:'both' #2427

Closed
6 tasks done
segrey opened this issue Dec 4, 2022 · 4 comments · Fixed by #2433
Closed
6 tasks done

Wrong stacktrace and broken debugging with esbuild.sourcemap:'both' #2427

segrey opened this issue Dec 4, 2022 · 4 comments · Fixed by #2433
Assignees

Comments

@segrey
Copy link
Contributor

segrey commented Dec 4, 2022

Describe the bug

Adding

  esbuild: {
    sourcemap: 'both'
  }

to vite.config.js breaks failed assertions stacktraces and makes it difficult to debug.

According to https://esbuild.github.io/api/#sourcemap, it should make easier to debug code. But actually, it breaks debugging Vitest tests.

Originally reported here. It might be not a Vitest issue, in this case I'd be grateful if you could re-route the issue.

Interestingly, everything works correctly without esbuild.sourcemap:'both'.
Would be great if configuring esbuild sourcemap wouldn't worsen experience of Vitest test development.

Reproduction

  1. Open the project
  2. Run vitest test/basic.test.ts => the failed assertion stacktrace wrongly points to 'test/basic.test.ts:14:40' whereas the assertion is actually failed on 'test/basic.test.ts:19'

image

  1. Also, it impedes debugging
    result

System Info

System:
    OS: Linux 5.4 Linux Mint 20.3 (Una)
    CPU: (12) x64 Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
    Memory: 14.35 GB / 31.21 GB
    Container: Yes
    Shell: 5.8 - /usr/bin/zsh
  Binaries:
    Node: 18.12.1 - ~/.nvm/versions/node/v18.12.1/bin/node
    npm: 8.19.2 - ~/.nvm/versions/node/v18.12.1/bin/npm
  Browsers:
    Chrome: 108.0.5359.94
  npmPackages:
    vite: latest => 3.2.4 
    vitest: latest => 0.25.3

Used Package Manager

npm

Validations

@segrey
Copy link
Contributor Author

segrey commented Dec 6, 2022

@sheremet-va Thank you for the prompt fix! It fixed the stacktrace indeed, but broke Vitest debugging in IntelliJ/WebStorm. It looks like a problem in IntelliJ/WebStorm, because the tests can still be debugged in VSCode. Unfortunarely, it's hard to release a hotfix of IntelliJ/WebStorm (moreover, it's would require Vitest users with IntelliJ/WebStorm to upgrade their IDEs which would be inconvenient for users). Sorry, may I ask you to restore the previous behavior? Ideally, it would be great to fix this issue and keep IntelliJ/WebStorm debugger working, but I guess it's might be not easy.

@sheremet-va
Copy link
Member

sheremet-va commented Dec 6, 2022

Sorry, may I ask you to restore the previous behavior?

I think if people experience issues, they can always revert Vitest version themselves. Currently the behaviour seems to be fixed on our side, so I don't really see any reason to revert the bug fix, since it was indeed a bug. The stack trace now always has correct source (can you confirm it? is it correct for you, but the issue is somewhere else?).

I have a thought on why the issue might happen. With the latest release source map is stored inside sourceMappingURL=...;source=vite-node;base64,(.*). Technically this is allowed syntax, but if WebStorm relies on it, it might break. If this is the issue, I can remove "source" part, until WebStorm fixes its parsing. But otherwise I don't know why this might be an issue.

@sheremet-va
Copy link
Member

@segrey can you confirm, if #2443 fixes it?

@segrey
Copy link
Contributor Author

segrey commented Dec 6, 2022

@sheremet-va This is great! Happy to confirm that #2443 solves the problem.

@github-actions github-actions bot locked and limited conversation to collaborators Jun 10, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants