3

I'm trying to debug an application in a multi-root project structure ( the root folder containing multiple projects ) and I'm having trouble getting vscode's debugger to recognize the sourcemaps that babel generates.

I have this in my launch.json

{ "configurations": [ { "console": "integratedTerminal", "internalConsoleOptions": "neverOpen", "name": "nodemon", "program": "${workspaceFolder}/project/index.js", "request": "launch", "cwd": "${workspaceFolder}/project", "restart": true, "sourceMaps": true, "runtimeExecutable": "nodemon", "runtimeArgs": [ "--inspect", "--exec", "${workspaceFolder}/node_modules/.bin/babel-node --config-file ./.babelrc.js", ], "skipFiles": [ "<node_internals>/**", ], "type": "pwa-node" } ] }

.babelrc.js

module.exports = { "sourceMaps": "both", "presets": [ [ "@babel/env", { "targets": { "node": "current" } }] ], "plugins": [ "@babel/plugin-proposal-class-properties", "source-map-support" ], }

and my index.js file

require('source-map-support/register') require('@babel/register'); require('@babel/polyfill'); require('./app.js');

When I add a breakpoint, it adds it to another location, when I click on the breakpoint itself, it opens up the compiled file and I see that the breakpoint is at the wrong location. I also see that the sourcemaps have been inlined, but it appears that vscode does not parse them properly, or not parse them at all.

I tried to play around with the settings involving the word sourcemap in their name, none of them seemed to work.

If I open the project the same way in Webstorm and attach to the running process, it parses the sourcemaps properly and stops where necessary, but vscode is unable to do so, for some reason.

I tried to open just this one project in vscode and move the .vscode folder inside of the project folder, but it didn't yield any results whatsoever, so I think it is irrelevant, I just decided to mention it if it helps with the issue.

Improve this question

1 Answer 1

Reset to default
1

I ended up editing the debugging configuration and I got it to work, somehow.

Here's the configurations

The project structure is as follows

/root /project 
// .babelrc { "env": { "development": { "plugins": [ "source-map-support" ] } }, "presets": [ [ "@babel/env", { "targets": { "node": "current" } }] ] }

Debug configuration

{ "name": "Debug", "port": 9229, "request": "attach", "restart": true, "cwd": "${workspaceFolder}/project", "skipFiles": [ "<node_internals>/**", "${workspaceFolder}/project" ], "type": "node" }

And the entry point looks like so

// index.js if (process.env.NODE_ENV === 'development') { require('source-map-support/register') } require('@babel/register'); require('@babel/polyfill'); require('main.js');

In order to allow the debugger to attach to this port ( the default port is 9229 ), you need to start the server with the --inspect flag.

I use nodemon to get it working and this is the script that I use

nodemon --inspect=127.0.0.1:9229 index.js

You can use just --inspect, as 127.0.0.1:9229 is the default host:port. However, if you are running more than one server on your machine, you will have port collisions, so you'd want to run them on different ports.

If you simultaneously run a client and a server application, you will need to use different ports. Do not forget to set the port accordingly in the launch.json file.

nodemon --inspect=127.0.0.1:9229 index.js nodemon --inspect=127.0.0.1:9230 index.js

Now, I'm not sure the source-map-support/register part is necessary ( though I barely got it to work and don't want to mess with it ).

When using babel/register, it transpiles the code at run-time, so the source code should remain intact, which is why source maps are not supposed to be necessary.

I'm using the attach mode, because I run the application from an external terminal. If you would like to run a launch configuration, have a look here for a recipe

Disclaimer

Debugging this way without an outDir, as I understand it, is rather slow. If you are working on a smaller project it might not bother you, the time after a save, before the app gets back on its feet is around 10 seconds for me.

I do not know how to get around this with this setup, if you are building your project its supposed to be faster. It might be faster with a launch configuration as well.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.