Debugger in vs-code does not stop at breakpoint but elsewhere #5380

bonham · 2024-03-13T21:05:03Z

Describe the bug

In vanilla project with vue3 + vitest + @testing-library/vue + node 18.18.2 or 20.11.1, setting and debugging breakpoints in vs-code on windows 11 does not work as expected. Debugger stops at wrong location. I am using vue single file components ( aka .vue files )

Seems to be transpiling and/or sourcemap issue.

The issue disappears when removing <style>...</style> section in .vue file

Reproduction

Create any vanilla vue project with simple single file component which contains all sections: template / script / style
Write a test with @testing-library/vue which is testing this component
Set a breakpoint within a .vue file
Run the test and watch where debugger stops
Result: Debugger stops at wrong line
Expected: Debugger should stop at correct line

Issue goes away when removing <style>...</style> section in .vue file

Example file SimpleComponent.vue

<template>
  <div>Hi {{ name }}</div>
  <div>Good</div>
</template>
<script setup>
import { ref } from 'vue'
const name = ref("Peter")
console.log("Nothing special") // set breakpoint here
</script>
<style>
.useless {
  color: green;
}
</style>

Example simple.spec.js

import { test } from 'vitest'
import { render } from '@testing-library/vue'
import SimpleComponent from './components/SimpleComponent.vue'

test("Component", () => {
  const renderResult = render(SimpleComponent)
  renderResult.findByText("mymessage")
})

Full example vanilla project to clone and reproduce: https://github.com/bonham/vitest-debug-issue-js

System Info

System:
    OS: Windows 11 10.0.22631
    CPU: (16) x64 AMD Ryzen 7 5700X 8-Core Processor
    Memory: 20.77 GB / 31.93 GB
  Binaries:
    Node: 20.11.1 - C:\Program Files\nodejs\node.EXE
    npm: 10.2.4 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Chromium (122.0.2365.80)
    Internet Explorer: 11.0.22621.1
  npmPackages:
    @vitejs/plugin-vue: ^5.0.4 => 5.0.4 
    vite: ^5.1.6 => 5.1.6 
    vitest: ^1.3.1 => 1.3.1

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.

The text was updated successfully, but these errors were encountered:

AriPerkkio · 2024-03-14T18:23:47Z

Can you test if @vitejs/plugin-vue@4.5.2 works?

This issue has come up before - it's not really Vitest related. I would guess that your breakpoints don't work even when debugging in browser during development.

Related discussions:

ghiscoding · 2024-03-18T14:04:10Z

This is most often related to bad or missing sourcemaps

bonham · 2024-03-18T20:57:49Z

Can you test if @vitejs/plugin-vue@4.5.2 works?

No, it has the same bug.

This issue has come up before - it's not really Vitest related. I would guess that your breakpoints don't work even when debugging in browser during development.

Breakpoints work well in browser. Breakpoints work well starting vite dev server in "Javascript debug terminal". So it's pretty much narrowed down to vitest I'd say.

Related discussions:

* [Coverage issue in vue files when upgraded with version 1.1.3  or 1.2.0 #4991](https://github.com/vitest-dev/vitest/discussions/4991)

^ This is not related to breakpoints

* [How to debug compents while running tests in VS code? #2874](https://github.com/vitest-dev/vitest/discussions/2874)

^ this is describing exactly the same problem.

Source maps are turned on as you can see in my minimalistic example: https://github.com/bonham/vitest-debug-issue-js/blob/main/vite.config.js

AriPerkkio · 2024-03-23T14:14:27Z

Breakpoints seem to work fine when using Chrome Dev tools:

vitest-5380.mov

bonham · 2024-03-23T16:57:50Z

Hi @AriPerkkio, yes you are right. I tried the same and also for me breakpoint works well. This is a good workaround.
( I never tried debugging this way before: https://vitest.dev/guide/debugging#node-inspector-e-g-chrome-devtools )

Summary:

breakpoints work well when using node inspector and chrome devtools
breakpoints do not work when running vitest in debug mode within vs-code ( I tested on mac and windows )

Idk, but seems not a vitest issue but maybe a vs-code issue ( vue plugin or whatever .... )

CreativeTechGuy · 2024-03-27T21:01:40Z

Not sure if this is helpful or not, but I can reproduce this issue (in the VS Code debugger) without vue at all, just a plain node app. Disabling coverage when a debugger is attached is a workaround but unfortunate.

bonham · 2024-03-27T21:23:28Z

Not sure if this is helpful or not, but I can reproduce this issue (in the VS Code debugger) without vue at all, just a plain node app. Disabling coverage when a debugger is attached is a workaround but unfortunate.

with vitest or even without vitest?

CreativeTechGuy · 2024-03-27T21:28:09Z

@bonham Oh sorry, yes with vitest.

CreativeTechGuy · 2024-03-27T21:40:31Z

I just tested debugging in VS Code with a node app instrumented with istanbul and esbuild and it works fine with breakpoints being where they should be. So I think there's something in vitest specifically that is causing the problem, I don't think that VS Code is the root problem (although maybe a contributing factor).

AriPerkkio · 2024-03-28T05:19:20Z

@CreativeTechGuy how can I reproduce this issue? Is it with covearge.provider: 'v8' or covearge.provider: 'istanbul'? Does it work with vitest --inspect-brk?

CreativeTechGuy · 2024-03-28T07:04:23Z

@AriPerkkio Sorry for the delay, this is gnarly. I couldn't reproduce it starting from an empty repo, but I started deconstructing my massive repo and I was able to get it down to a few dozen lines total across all files. I've put a ton of information and very detailed steps in the repo README. Let me know if you are able to reproduce. I've been able to reproduce it across two computers (Windows 10 & 11) so far so hopefully you can too.

https://github.com/CreativeTechGuy/vitest-coverage-debugger-issue-repro

MarvinKubus · 2024-04-04T10:47:31Z

Hi @AriPerkkio, yes you are right. I tried the same and also for me breakpoint works well. This is a good workaround. ( I never tried debugging this way before: https://vitest.dev/guide/debugging#node-inspector-e-g-chrome-devtools )

Summary:

breakpoints work well when using node inspector and chrome devtools

breakpoints do not work when running vitest in debug mode within vs-code ( I tested on mac and windows )

Idk, but seems not a vitest issue but maybe a vs-code issue ( vue plugin or whatever .... )

We are experiencing this same problem at the moment and for us the workaround going through the Chrome Devtools is also working, but a lot less convenient to use.

mummybot · 2024-07-26T08:58:09Z

We have this issue at our work across multiple VueJS and Nuxt projects. Various developers have spent collective weeks trying to solve to no success.

AriPerkkio · 2024-07-26T09:22:40Z

There's some more discussion about VS Code not respecting inline source maps here: #5605. Check the solution at the end and see if it works for you.

mummybot · 2024-07-26T14:06:06Z

Not sure if the solution at the end is quite our problem - they seem to be trying to debug node_modules, where we are failing on our application code. Trying their fix of this.showExternalized didn't fix anything :( Tried it on two separate projects.

AriPerkkio · 2024-07-28T07:08:46Z

Issue goes away when removing <style>...</style> section in .vue file

To me this sounds like source mapping issue. As soon as I remove <style> tags from *.vue files, VS code debugger starts to work. It's like if the <style> tag is introducing another transform step that messes up the source maps completely.

Debugging in vs code without style tags works:

vitest-vscode-vue-debug.mp4

But when looking at the source maps they look just fine:

With style tags: https://evanw.github.io/source-map-visualization/#MjYyNwBjb25z...
Without style tags: https://evanw.github.io/source-map-visualization/#MjQzNwBjb2...

So to summarize:

Chrome dev tools work with style tags ✅
Chrome dev tools work without style tags ✅
VS code works without style tags ✅
VS code does not work with style tags ❌

We have quite many issues that are related to VS Code not being able to handle source maps. Does Vue debugging work in VS Code in general, without Vitest?

sheremet-va · 2024-07-28T07:31:15Z

We have quite many issues that are related to VS Code not being able to handle source maps. Does Vue debugging work in VS Code in general, without Vitest?

By default, Vitest strips all CSS styles. Does debugger work if test.css is enabled?

rafagsiqueira · 2024-09-06T20:47:52Z

Having the same issue with an angular application. Breakpoints are all messed up when debugging tests. Works perfectly when debugging application ran with ng serve.

valneras · 2024-09-17T15:23:30Z

Same issue on my side with Angular+analogjs+Vitest: debugger moves badly on breakpoints, see gif.

I also followed this doc https://vitest.dev/guide/debugging#intellij-idea but it doesn't work. Same issue in VsCode with vitest plugin.

I created a repo to reproduce this issue: https://github.com/valneras/jest-vs-vitest
Does someone can clone this repo to confirm this issue? is it related to vitest or another dependency (analogjs, angular?)

We blocked the migration on Vitest because of that :(
Thanks.

AriPerkkio · 2024-09-17T15:52:43Z

@valneras there's an open issue on Analog that's related to the plugin's sourcemap issues: analogjs/analog#1211

We blocked the migration on Vitest because of that

So are you able to use some other testing framework with @analogjs/vite-plugin-angular and it works fine?
This isn't reallly issue on Vitest, it's the plugin.

When looking at the source maps of your project, it's clearly visible that they are completely off when @analogjs/vite-plugin-angular is enabled. No wonder why the breakpoints don't work 😄

https://evanw.github.io/source-map-visualization/#NDYxNABpbXBvcnQ...

And when I remove @analogjs/vite-plugin-angular and run the tests, the source maps are fine:

https://evanw.github.io/source-map-visualization/#MTA4OABpbXBvc...

brandonroberts · 2024-10-10T19:46:57Z

@AriPerkkio any tips would be welcomed on this one. The sourcemaps work correctly in the browser, so I'm trying to figure out why they are off with Vitest. We disable esbuild so the sourcemaps are produced through Angular's compilation process

brandonroberts · 2024-10-11T03:16:01Z

Example of a produced sourcemap with the plugin

I did grab the generated source from using the vite-plugin-inspect package which is loaded in the browser though

app.component.ts

app.component.spec.ts

https://github.com/brandonroberts/analog-vitest-sourcemaps

AriPerkkio · 2024-10-11T08:18:11Z

@brandonroberts you can see the broken source maps in https://github.com/valneras/jest-vs-vitest. But its Vite config is not similar as in your reproduction. It's using @analogjs/vite-plugin-angular directly, while your config uses plugin from @analogjs/platform.

I tested the app.component.spec.ts from @valneras's setup in yours, and it works correctly there: https://evanw.github.io/source-map-visualization/#NDgzMgBp...

So @valneras, update your project to match https://github.com/brandonroberts/analog-vitest-sourcemaps and debugger should work just fine.

brandonroberts · 2024-10-11T12:47:29Z

I did find that I needed to explicitly disable esbuild in the vite.config.mts also for the breakpoints to be correct

/// <reference types="vitest" />

import angular from '@analogjs/vite-plugin-angular';

import { defineConfig } from 'vite';

// https://vitejs.dev/config/
export default defineConfig(({ mode }) => {
  return {
    esbuild: false, // completely disable esbuild
    plugins: [
      angular(),
      
    ],
    test: {
      globals: true,
      environment: 'jsdom',
      setupFiles: ['src/test-setup.ts'],
      include: ['**/*.spec.ts'],
      reporters: ['default'],
    },
    define: {
      'import.meta.vitest': mode !== 'production',
    },
  };
});

We are disabling esbuild inside the analog vite plugin, but its not getting applied early enough for Vitest to pick it up, as the VitestPlugin is enforced using pre. We can add an additional plugin internally that sets esbuild: false early enough for it to pick it up

rafagsiqueira · 2024-10-11T13:38:10Z

@AriPerkkio and @brandonroberts I tried both approaches. With the @analogjs/platform the gutter icons seem to go to the right place, but breakpoints still jump around and debugger stops at the wrong line. When disabling esbuild, as @brandonroberts suggests, Gutter icons are all wrong as well as breakpoints.

brandonroberts · 2024-10-11T14:31:29Z

@AriPerkkio and @brandonroberts I tried both approaches. With the @analogjs/platform the gutter icons seem to go to the right place, but breakpoints still jump around and debugger stops at the wrong line. When disabling esbuild, as @brandonroberts suggests, Gutter icons are all wrong as well as breakpoints.

Ok. I see that also. If I use test.server.debug.dumpModules in the vite.config.ts and load it into the sourcemap visualizer, the lines are off there also.

Sample sourcemap from app.component.spec.ts

Oddly enough, if I remove the first line in the file, they line up correctly. Let's continue the discussion here

analogjs/analog#1211

brandonroberts · 2024-10-12T01:47:11Z

Just to provide an update on the Analog side, I landed a fix in Analog 1.9.0-beta.12 that uses esbuild to fix the sourcemaps after the files are transformed, which fixes IDE support and coverage reports. Open to recommendations on a better solution, but it solves the issues.

analogjs/analog#1399

bonham added the pending triage label Mar 13, 2024

AriPerkkio added help wanted Extra attention is needed and removed pending triage labels Jul 28, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Debugger in vs-code does not stop at breakpoint but elsewhere #5380

Debugger in vs-code does not stop at breakpoint but elsewhere #5380

bonham commented Mar 13, 2024 •

edited

Loading

AriPerkkio commented Mar 14, 2024

ghiscoding commented Mar 18, 2024 •

edited

Loading

bonham commented Mar 18, 2024

AriPerkkio commented Mar 23, 2024

bonham commented Mar 23, 2024

CreativeTechGuy commented Mar 27, 2024

bonham commented Mar 27, 2024

CreativeTechGuy commented Mar 27, 2024

CreativeTechGuy commented Mar 27, 2024

AriPerkkio commented Mar 28, 2024

CreativeTechGuy commented Mar 28, 2024

MarvinKubus commented Apr 4, 2024

mummybot commented Jul 26, 2024

AriPerkkio commented Jul 26, 2024

mummybot commented Jul 26, 2024 •

edited

Loading

AriPerkkio commented Jul 28, 2024

sheremet-va commented Jul 28, 2024

rafagsiqueira commented Sep 6, 2024 •

edited

Loading

valneras commented Sep 17, 2024

AriPerkkio commented Sep 17, 2024 •

edited

Loading

brandonroberts commented Oct 10, 2024

brandonroberts commented Oct 11, 2024

AriPerkkio commented Oct 11, 2024

brandonroberts commented Oct 11, 2024

rafagsiqueira commented Oct 11, 2024

brandonroberts commented Oct 11, 2024 •

edited

Loading

brandonroberts commented Oct 12, 2024 •

edited

Loading

Debugger in vs-code does not stop at breakpoint but elsewhere #5380

Debugger in vs-code does not stop at breakpoint but elsewhere #5380

Comments

bonham commented Mar 13, 2024 • edited Loading

Describe the bug

Reproduction

System Info

Used Package Manager

Validations

AriPerkkio commented Mar 14, 2024

ghiscoding commented Mar 18, 2024 • edited Loading

bonham commented Mar 18, 2024

AriPerkkio commented Mar 23, 2024

bonham commented Mar 23, 2024

CreativeTechGuy commented Mar 27, 2024

bonham commented Mar 27, 2024

CreativeTechGuy commented Mar 27, 2024

CreativeTechGuy commented Mar 27, 2024

AriPerkkio commented Mar 28, 2024

CreativeTechGuy commented Mar 28, 2024

MarvinKubus commented Apr 4, 2024

mummybot commented Jul 26, 2024

AriPerkkio commented Jul 26, 2024

mummybot commented Jul 26, 2024 • edited Loading

AriPerkkio commented Jul 28, 2024

sheremet-va commented Jul 28, 2024

rafagsiqueira commented Sep 6, 2024 • edited Loading

valneras commented Sep 17, 2024

AriPerkkio commented Sep 17, 2024 • edited Loading

brandonroberts commented Oct 10, 2024

brandonroberts commented Oct 11, 2024

AriPerkkio commented Oct 11, 2024

brandonroberts commented Oct 11, 2024

rafagsiqueira commented Oct 11, 2024

brandonroberts commented Oct 11, 2024 • edited Loading

brandonroberts commented Oct 12, 2024 • edited Loading

bonham commented Mar 13, 2024 •

edited

Loading

ghiscoding commented Mar 18, 2024 •

edited

Loading

mummybot commented Jul 26, 2024 •

edited

Loading

rafagsiqueira commented Sep 6, 2024 •

edited

Loading

AriPerkkio commented Sep 17, 2024 •

edited

Loading

brandonroberts commented Oct 11, 2024 •

edited

Loading

brandonroberts commented Oct 12, 2024 •

edited

Loading