Open bgoscinski opened 2 months ago
Could you point out the incorrect source map? You can use vite-plugin-inspect
or VITE_NODE_DEBUG_DUMP=1 vitest
to capture the source maps. Note that VITE_NODE_DEBUG_DUMP
adds a comment on top of the file - you'll need to remove that manually before using it.
Running VITE_NODE_DEBUG_DUMP=1 npx vitest run
generated a bunch of files in .vite-node/dump folder. Turns out that none of the files coming from node_modules have source maps. Here's a sample:
I even tried doing this 👇 but it didn't change anything
diff --git a/vite.config.ts b/vite.config.ts
index 673c4de..2ffa6df 100644
--- a/vite.config.ts
+++ b/vite.config.ts
@@ -7,6 +7,7 @@ import { defineConfig } from 'vite'
export default defineConfig({
test: {
server: {
+ sourcemap: 'inline',
deps: {
inline: ['date-fns']
}
I figured that when I change this https://github.com/vitest-dev/vitest/blob/48fba19022ebb1f8f9c6f04c90cf5f362513a6a3/packages/vite-node/src/server.ts#L307-L309
in this way:
const sourcemap = this.options.sourcemap ?? 'inline'
- if (sourcemap === 'inline' && result && !id.includes('node_modules'))
+ if (sourcemap === 'inline' && result && !(await this.shouldExternalize(id)))
result = await this.processTransformResult(filepath, result)
Then running with VITE_NODE_DEBUG_DUMP=1
will spit out files with source map. Here's the output for add.mjs that I got with the above change:
I put this file into Source map visualization tool and, taking into account the comment line added by VITE_NODE_DEBUG_DUMP
at the top, it seems to be generating a correct sourcemap.
Sadly, this doesn't help VS Code in any way. It still points at line 52 just after stepping into the add
function :(
@AriPerkkio do you have any more pointers?
@bgoscinski could you show in a recording how this should behave when running without Vitest? Use file like below with VSCode's debugger:
import { add } from "date-fns";
add(0, { days: 1 });
https://github.com/vitest-dev/vitest/assets/14806298/77c68c01-bf6b-413a-a92e-7abd71e50a6a
Does it work any better if you disable VSCode's "Pretty print for debugging"
option?
Chrome Devtools with vitest --inspect-brk
seems to work correctly even without the proposed fix of https://github.com/vitest-dev/vitest/issues/5605#issuecomment-2079507295.
@AriPerkkio Sure! Here's how it works without vitest/how it should work:
https://github.com/vitest-dev/vitest/assets/5730169/bfa0c141-5293-44bb-ad27-4955336233d3
I updated reproduction repo with launch script. See https://github.com/bgoscinski/repro-vitest-sourcemap/commit/42e048b2ee5a0d36ab9c993811ff9b432df9dce0
Does it work any better if you disable VSCode's "Pretty print for debugging" option?
Clicking this doesn't seem to do anything
Chrome Devtools with
vitest --inspect-brk
seems to work correctly even without the proposed fix of #5605 (comment).
Good to know, however switching to chrome devtools breaks my flow :(
Sure! Here's how it works without vitest/how it should work
Using your reproduction in fresh Github Codespaces I'm unable to set breakpoints like shown in the video above. 🤷
https://github.com/vitest-dev/vitest/assets/14806298/91afc380-5a3b-43ba-a112-a9c1bf9bac69
Yeah, in Github Codespaces I get the same result as you do... Could you try in "normal" vscode?
Edit:
I think Github Codespaces treats the whole destructuring assignment as a "atomic" thing so, when we run with Debug - node
and "step into" the add function we land on line 48 (correct), and then "step over" for some reason goes directly to the next line that we can pause on - line 58 (the one with assignment to _date
). I guess that's mostly fine because at least it stops at lines that it's about to execute.
Anyway, when I launch "Debug - vitest" script it breaks the same way as my local vscode installation:
https://github.com/vitest-dev/vitest/assets/5730169/2cfb889e-7737-487b-bdf1-c64667b31e6d
https://github.com/vitest-dev/vitest/assets/5730169/c3997ca3-5188-4b25-bdae-9217cf797435
Yeah, in Github Codespaces I get the same result as you do... Could you try in "normal" vscode?
I get the same results on local VSCode and Github Codespaces.
But I can reproduce the issue shown on videos of https://github.com/vitest-dev/vitest/issues/5605#issuecomment-2081583409. Debugger lands on incorrect lines (L52,L62) - looks like there's some offset that's probably caused by Vite's transforms that are not included in source maps. Or rather the file is transformed but no source maps have been generated like shown in https://github.com/vitest-dev/vitest/issues/5605#issuecomment-2074762769.
Let's focus on making the debugger land on same lines (L48,L58) when used with Vitest. Breakpoints in the destructured object L47-L55 work so inconsistenly even without Vitest that we shouldn't focus on those right now.
Removing columnOffset
from vm.runInThisContext
seems to fix this:
@sheremet-va that one is used for getting proper stack traces, right?
@AriPerkkio Thanks for looking into it but I'm afraid it breaks the source mapping even more. See the video below and notice that with columnOffset
path to the add.mjs uses forward slashes and shows the real contents of the add.mjs file from node_modules - the one with ESM imports. Without columnOffset
the file has path consisting of backslashes and it starts with a backslash. VSCode opens it in a new tab as if it was a different file from "the real" add.mjs in node_modules. It also shows transformed __vite_ssr_import__
calls instead of original ESM imports :(
https://github.com/vitest-dev/vitest/assets/5730169/8cd8f448-c030-48bc-87e3-16ea53eec09f
Spent couple of more hours looking into this and I have no idea how to fix this. Even when source maps are enabled for the inlined deps, VSCode will not follow them. I also tried to apply vite-node's wrapper in those source maps and it still didn't work. Not sure what to try next. Maybe if Vite's SSR transform didn't change the file's line count it could work automatically. Right now SSR transform may add some extra lines.
Describe the bug
Source maps in inlined deps are off by a few lines in VS Code debugger
Reproduction
https://github.com/bgoscinski/repro-vitest-sourcemap
pnpm install
code test/the.test.ts
add
function implementationhttps://github.com/vitest-dev/vitest/assets/5730169/4d1b9170-5ca4-4bcd-be5e-f3c3166a1b8e
System Info
Used Package Manager
pnpm
Validations