Closed Adriaanse closed 6 years ago
@Adriaanse Interesting! Can you provide some more details on your setup? Sounds like a big with the break-on-load breakpoints @roblourens
I am running 64 bit windows 7 (enterprise edition) with the latest versions of node, nmp and Vs code.
Just to see if i can reproduce it i just uninstalled node js and VS Code to start from scratch, steps to reproduce:
1) reinstalled current LTS version of Node.js 8.9.4 with npm 5.6.0 (64 bit)
2) reinstalled stable build of VS Code version 1.20.1 (64 bit)
3) added debugger for chrome 4.1.0 and vetur 0.11.7 extensions in VS Code
from there on i follow the recipe:
npm install -g vue-cli
vue init webpack vuejs-webpack-project project name: hello-world Vue build: runtime + compiler vue-router: yes ESLint: yes, standard preset unit tests yes, Karma & Mocha e2e tests yes npm install yes, use npm
when done, i open the folder in VS Code, and follow the Vetur setup instructions by adding a jsconfig.json file:
{ "include": [ "./src/*/" ] }
following the recipe i edit config.index.js to set devtool: 'source-map' for both environments
going to the debug configuration, in launch.json i copy-paste this configuration below the default one:
{ "type": "chrome", "request": "launch", "name": "vuejs: chrome", "url": "http://localhost:8080", "webRoot": "${workspaceFolder}/src", "breakOnLoad": true, "sourceMapPathOverrides": { "webpack:///src/": "${webRoot}/" } }
then finally i set the breakpoint in HelloWorld.vue, and in the terminal i execute:
npm run dev
now when select the "vuejs: chrome" and start debugging the debugger stops in a node internal VM*** which reads:
;(function (e){let t={};if(e.hasOwnProperty("VUE_DEVTOOLS_GLOBAL_HOOK"))return;const n={Vue:null,on(e,n){(t[e="$"+e]||(t[e]=[])).push(n)},once(e,n){const o=e;function r(){this.off(o,r),n.apply(this,arguments)}(t[e="$"+e]||(t[e]=[])).push(r)},off(e,n){if(e="$"+e,arguments.length){const o=t[e];if(o)if(n)for(let e=0,t=o.length;e<t;e++){const t=o[e];if(t===n||t.fn===n){o.splice(e,1);break}}else t[e]=null}else t={}},emit(e){let n=t[e="$"+e];if(n){const e=[].slice.call(arguments,1);for(let t=0,o=(n=n.slice()).length;t<o;t++)n[t].apply(this,e)}}};n.once("init",t=>{n.Vue=t,t.prototype.$inspect=function(){const t=e.VUE_DEVTOOLS_INSPECT;t&&t(this)}}),n.once("vuex:init",e=>{n.store=e}),Object.defineProperty(e,"VUE_DEVTOOLS_GLOBAL_HOOK",{get:()=>n})})(window)
and it will repeatedly stop there as components are loaded, making it not-so-usefull for debugging.
This is partially solved by setting breakOnLoad to false, now the debugger stops at the statement where i put the breakpoint, except that a breakpoint set in the "export default {}" script of a component will still end up in the transpiled code.
However, as long as i put my breakpoints outside the "export default {}" script in the .vue file, all is well and the debugger works great !
I have attached my project, node_modules excluded
@Adriaanse Interesting thanks for all the details! Can I get you to try disabling the Vue DevTools extension in Chrome and still keep breakOnLoad around. Does the debugger still stop at random places when components are loaded?
I suppose you mean the Vue.js DevTools ? i have disabled that and there is no other chrome extension running. Still the behavior is the same, this VM*** code popping up all the time unless i set breakOnLoad to false,
@Adriaanse Yes meant Vuejs devtools. Interesting. We shall investigate.
Some more information that may be helpfull;
Besides the hello world template i have been using your recipe on about 4 different projects created by colleagues for which i am not sure how they have been scaffolded and otherwise configured.
remarkably, for some projects i need to set:
"webRoot": "${workspaceFolder}" // skipping the source prefix
for some projects i also need to change:
"sourceMapPathOverrides": { "webpack:///": "${webRoot}/" // skipping the source prefix
And, if that is the case the default chrome debug config also works just fine.
So, there appears to be some confusion about what the root of my web project is but i have no clue as to where this comes from.
Once i get these projects to debug, the debugger does work well, even if i leave breakOnLoad set to true and/or put my breakpoints in the "export default section" of a component.
@roblourens Do you have any ideas here? Could the Vue project trigger some breakpoints or exceptions?
I can't repro it. Could you set "trace": true
in your launch config, run it again, and attach the log here?
This afternoon my VSCode updated to 1.21 and now i cannot reproduce this VM code popping up all the time, which i think is good.
However in the hello world template i attached in my second message, if i put a breakpoint (as instructed in the recipe) in HelloWorld.vue at line 90 i still end up in transpiled app.js code and the breakpoint appears as if it has moved to line 1037.
I enabled trace and did the same with breakOnLoad set to false as well as true and zipped the log for you, but i do not see a difference in behavior now, so i suggest we just close this issue assuming the 1.21 update fixed it.
The confusion about webroot remains, the first Vuetify template based project i am working on now with a colleague requires that i remove the /src prefix from lounc.json for it to work, and in this case the debugger works just fine with the default chrome config:
{
"type": "chrome",
"request": "launch",
"name": "Launch Chrome against localhost",
"url": "http://localhost:8080",
"trace": true,
"webRoot": "${workspaceFolder}"
},
In case your interested the log for this is in vscode-chrome-debug.zip. vscode-chrome-debug.zip
@Adriaanse You might have have hit this known problem for Vue.js: https://github.com/vuejs/vue-loader/issues/1163, which is also mentioned in our debugging recipe: https://github.com/Microsoft/vscode-recipes/tree/master/vuejs-cli
I noticed both of these issues yes, for me messing a bit with the webRoot setting got me out of trouble and it is working just perfectly now, knock on wood.
Glad you got things working @Adriaanse.
Following the Vue.js debugging recipe with the current (1.20.1) VS Code it works like a charm for me (in the VueJS webpack HelloWorld project), thank you all for posting this !
One thing though, the debugger would time after time stop in some node VM thread which made the debugging process quite frustrating.
It took me a while to figure out that putting the BreakOnLoad option to false solves this and the debugging works impressively well now !
I would suggest to change this in the recipe to make the VS Code experience even smoother...