Vue-cli: Debugging in VS Code and Chrome not working with TypeScript

[YoannBureau]

Version

3.1.1

Reproduction link

https://github.com/YoannBureau/vuejs-vscode-ts-ko

Node and OS info

NPM 6.4.1

Steps to reproduce

• npm install
• in vs code, install "Debugger for Chrome" extension if not done yet
• npm run serve
• set a breakpoint in HelloWorld.vue line 43
• start debug using "vuejs: chrome" debug config (FYI I reproduced the same steps as here: https://fr.vuejs.org/v2/cookbook/debugging-in-vscode.html )
• click the button in the component

What is expected?

Breakpoint should be hit

What is actually happening?

Breakpoint is not hit

---

It's working great with Js, but ko with Ts

[YoannBureau]

Any idea, friends?

[amsokol]

+1

[AidanGG]

I was able to set breakpoints directly in Chrome by going to Sources, webpack://. and this would work, but is definitely suboptimal. Are there perhaps any better options?

[YoannBureau]

Well, what we are looking for is setting breakpoints directly in vs code, not in Chrome. What @AidanGG did work but it's not practical at all.

[LinusBorg]

Edit: Forget the following, I misread your whole issue, mixing it up with an older one about mocha-webpack

unfortunately, it seems that the webpack-mocha based setup doesn't work with the vacode debugger.

Edit: See here: https://github.com/zinserjan/mocha-webpack/issues/266

Doesn't seem to be vue-cli specific. Maybe there's something for you to try in that issue? We can go and work from there...

[YoannBureau]

Can the team reproduce the isssue? Might be cool to have this feature working :)

[SeanMBe]

Jetbrains is tracking this issue also reported for webstorm here: https://youtrack.jetbrains.com/issue/WEB-34557

Is there anything I can do to help resolve?

[ffxsam]

Just noticed this tonight when I was following the instructions on debugging using VS Code, which do not work for Vue TS projects.

[ffxsam]

This launch.json works for me:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "chrome",
      "request": "launch",
      "name": "vuejs: chrome",
      "url": "http://localhost:8080",
      "webRoot": "${workspaceFolder}",
      "breakOnLoad": true,
      "sourceMaps": true,
      "disableNetworkCache": true,
      "sourceMapPathOverrides": {
        "webpack:///*": "${webRoot}/*",
        "webpack:///./*": "${webRoot}/*",
        "webpack:///src/*": "${webRoot}/src/*"
      }
    }
  ]
}

[jschoedt]

@ffxsam when you write "works" - are you able to set breakpoints in vue files? I am only able to debug ts files.

[ffxsam]

@jschoedt Yep, breakpoints in vue files works great. The only thing that doesn't seem to work with the debugger is when you hit async functions. Things really fall apart then.

[ayyron-lmao]

Is this isolated to TypeScript? I am not using typescript and I've found that my breakpoints in async functions are hit but it falls apart when the first await is executed; the debugger gets lost and can't step past that line.

[rdhelms]

Here's a slight variant to the example that @ffxsam provided. This configuration is working decently for us with Vue Cli 4.2.3 and TypeScript:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "chrome",
            "request": "launch",
            "name": "vuejs: chrome",
            "url": "http://localhost:8080",
            "webRoot":"${workspaceFolder}",
            "breakOnLoad": true,
            "sourceMapPathOverrides": {
                "webpack:///./*": "${webRoot}/*"
            },
            "skipFiles": [
                "${workspaceFolder}/node_modules/**/*"
            ]
        }
    ]
}

So far we haven't seemed to need the other sourceMapPathOverrides, and adding the skipFiles seemed to help. I'd be interested to know if anyone else finds use cases for the other sourceMapPathOverrides.

I also want to reiterate the strangeness with trying to debug some await code. Sometimes it works, but other times VSCode totally won't allow setting a breakpoint on a line with await. Our current workaround is literally to write a non-async line of code above or below the await-ed line, and stick the breakpoint there. So there definitely still seems to be some room for improvement.

await someAsyncThing()  // Can't add breakpoint here
console.log('stop here')  // Can add breakpoint here

[geekox86]

Greetings all. I am using @vue/cli version 4.2.3 and breakpoints do not work in JetBrains IDE's when using TS + Vue SFC's.

We just want to know what is root of the issue so maybe we can help with workarounds?

[rdhelms]

@geekox86 I'm not sure if anyone has a very clear understanding of the "root" of the issue except that it seems like varying the source map paths can make it better or worse.

But none of the configurations listed here seem to completely fix the problem. Even the example configuration that I posted above has not been working quite as smoothly as I initially thought. And even when I thought it was working well, it still was very broken when debugging async/await code.

I'm curious if anyone has tried debugging a Vue+TS project using the new JavaScript Debugger extension that VSCode mentioned in its March update

[geekox86]

@rdhelms I just tried it on the mentioned new JS debugger and I can confirm that issue still exists. Debugging TS code however is much better however.

[zhaitianye]

Here's a slight variant to the example that @ffxsam provided. This configuration is working decently for us with Vue Cli 4.2.3 and TypeScript:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "chrome",
            "request": "launch",
            "name": "vuejs: chrome",
            "url": "http://localhost:8080",
            "webRoot":"${workspaceFolder}",
            "breakOnLoad": true,
            "sourceMapPathOverrides": {
                "webpack:///./*": "${webRoot}/*"
            },
            "skipFiles": [
                "${workspaceFolder}/node_modules/**/*"
            ]
        }
    ]
}

So far we haven't seemed to need the other sourceMapPathOverrides, and adding the skipFiles seemed to help. I'd be interested to know if anyone else finds use cases for the other sourceMapPathOverrides.

I also want to reiterate the strangeness with trying to debug some await code. Sometimes it works, but other times VSCode totally won't allow setting a breakpoint on a line with await. Our current workaround is literally to write a non-async line of code above or below the await-ed line, and stick the breakpoint there. So there definitely still seems to be some room for improvement.

await someAsyncThing()  // Can't add breakpoint here
console.log('stop here')  // Can add breakpoint here

hello, 你好，在断点过程中，我遇到了同样的问题，请问有没有解决办法。

methods: {
    handleTest(){
      console.log(this) // VueComponent
    },
    async handleTest2(){
      console.log(this) // undefined
    }
  }

[rdhelms]

@zhaitianye Still no solution that I'm aware of 🙁

[zhaitianye]

@rdhelms

methods: {
    handleTest(){
      console.log(this) // VueComponent
    },
    async handleTest2(){
      console.log(this)  // undefined
      let that = this
      console.log(that) // VueComponent
    }
  }

This is the temporary solution I know of. IN Google Chrome Debug

[Moseyza]

using vue/cli 4.4.6 no solution works for me!
is there any solution for enable breakpoints?

[rdhelms]

This is what we currently use. It seems to allow setting breakpoints with mostly successful results. Trying to use VS Code's "step over" functionality pretty much always ends up either jumping to the top of the component export default class SomeComponent... or in some js/app.js asyncGeneratorStep code. The breakpoints themselves do seem to generally work, though sometimes it works better to put the breakpoint on a line either above or below any actual async/await logic rather than directly on it.

Also note that in order for this to work, npm run serve has to be run separately prior to starting this debug program.

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "pwa-chrome",
            "request": "launch",
            "name": "vuejs: chrome",
            "url": "http://localhost:8080",
            "webRoot":"${workspaceFolder}",
            "sourceMapPathOverrides": {
                "webpack:///./*": "${webRoot}/*"
            },
            "skipFiles": [
                "${workspaceFolder}/node_modules/**/*"
            ]
        }
    ]
}

Incidentally, I'm not actually sure if the webRoot or sourceMapPathOverrides properties are necessary, but removing skipFiles sometimes lands me in some regenerator-runtime node_module.

[lmexo]

Before you read: This will not provide any solution but maybe helps finding a direction to solve the problem.

I also spent a lot of time in this problem but to me it actually does not seem to be a problem with vue-cli or the source-map-path-mapping, but the vue-loader (currently using with vue-loader 16.0.0-rc.2). According to vscode-chrome-debug's trace, the sourcemaps are found and pointing as expected, so the source files should be resolved. Looking in Chrome, the files with the hash-information do contain the code i do not care for debugging:

The problem is, however, when i place a breakpoint in vscode in foobar.ts, it will not be hit. Instead, when placing the breakpoint in chrome (also foobar.ts) it will be hit (in chrome, but vscode also stops).

As far as i know, chrome reconstructs foobar.ts' sources from the source-map but does not really know the original file. Looking at vscode-chrome-debug's trace again, it seems chrome itself cannot resolve the position of the breakpoint when it is requested by vscode. I don't know much about chrome's devtool-api, but the vscode-chrome-debug-trace look a bit like (working example, e.g when not using typescript but javascript or a typescript file not loaded through the vue-loader)
vscode: place breakpoint near line 2, column 0 in file main.ts
chrome: breakpoint placed in line 2, column 5 in file main.ts
vscode: get neares breakpoints
chrome: in line 2 you may set breakpoint in column 5, 12, ...

But when placing breakpoints in typescript referenced from vue-file it is more like
vscode: place breakpoint near line 2, column 0 in file foobar.ts
chrome: ... ... I will let you know when i stop somehere in the bundle.js.

Finally i would assume that the reverse-lookup in the source-map does result in the correct code-segment (if one can say it like that, i am not that deep into the topic of source-maps)

But again: this only happens, when using typescript in vue-components, javascript does not cause any problem.

[lmeysel]

I stepped a bit further now, looking again in the logs of the vscode-chrome-debugger trace, and found something confusing:

There are two sourcemap-tags for app.ts (which is referenced from app.vue), saying "SourceMap: mapping .../app.ts". The order of the sourcemap-tags roughly matches the order of the sources as provided in the source-map. So i changed the corresponding (second) file in the source-map and suddenly the vscode-debugger works as intended. It "feels" like the second mapping overrides the first one, thus the breakpoint set in the first (the real app.ts) will be resolved to the "second" app.ts (which in fact is "app.ts?xxxx". But since the second one is not found by vscode, it kind of falls back to the bundle.js. Voilà.

Now the question is how to solve it. But if I am on the right path this issue is not part of vue-cli (it also appears when using laravel-mix and probably also when only using the vue-loader with webpack only).

[geekox86]

Greetings all. Any progress on this long standing issue?
Is any body able to debug Vue SFC files with TypeScript using Vue CLI 4.5.9?