Meteor 1.6 server debugging with VS Code

Since Meteor 1.6 is nearly out (presumably, as it’s on 1.6-rc.6) I wanted to see if I can get debugging working properly with VS Code. I got it working!


  "version": "0.2.0",
  "configurations": [
      "name": "Launch Chrome against localhost:3000, with sourcemaps",
      "type": "chrome",
      "request": "launch",
      "url": "http://localhost:3000",
      "webRoot": "${workspaceRoot}",
      "userDataDir": "${workspaceRoot}/.vscode/out/chrome",
      "runtimeExecutable": "/Applications/Google Chrome",
      "sourceMaps": true
      "type": "node",
      "request": "launch",
      "name": "Meteor Server",
      "cwd": "${workspaceRoot}/",
      "runtimeExecutable": "${workspaceRoot}/.meteor/local/dev_bundle/bin/npm",
      "restart": true,
      "timeout": 30000,
      "stopOnEntry": false,
      "sourceMaps": true,
      "protocol": "inspector",
      "port": 9229

I’m starting with:

meteor run --inspect-brk --settings settings-development.json

Now I can start my server, and then launch the debugger and go on setting break points. It’s been a while since I actively used a debugger, but I remember it being very useful, and am excited to see if it improves my workflow for Meteor dev.


When running this against a server instance, it requires pressing the play button between each save. Is there a way to get that to happen automatically?

Have you tried using --inspect instead of --inspect-brk? (brk = “break”).

1 Like

Oh right! I guess I just have to use the right one depending on what I am debugging (-brk for startup stuff, so I can set break points, and no -brk for everything else).

I now have a couple of scripts in my package.json file:

  "scripts": {
    "start": "meteor run",
    "debug": "meteor run --inspect",
    "debug-brk": "meteor run --inspect-brk"

Personally I leave --inspect on by default as there’s no noticeable overhead and it saves restarting the server when you notice something and want to debug.

Debugging is now really easy thanks to 1.6 but the only slight issue I still have is using the Debugger for Chrome plugin in VS Code, when an exception fires in the debug console it doesn’t reverse lookup the sourcemap for each line of the exception, just the one that prints it, which in a Meteor app is the Meteor._debug function. If I open the console in Chrome each line is clickable so I can actually go to where the issue is. Anyone know if that’s fixable with some config ? Or do we need some work from the VS code team ?

1 Like

Can we have some official documentation about the new way to debug in Visual Studio Code?

I noticed a reference to MacOS for runtimeExecutable in the launch.json example, so I just set runtimeExecutable to null, which seems to work in Windows OS.

I’ve tried this settings and they work all right for the app code, but I still cannot set breakpoints on packages. My project has several packages which are embedded into the main project source code (under the /packages folder) and the only way I can set breakpoints is by adding a ‘debugger’ statement to wherever I need them. Is there a solution for this?

Are you on Windows? This config example has debugger settings for 2 targets - the node.js server, and Chrome. Only the Chrome example has a reference to MacOS, but it shouldn’t effect the node.js settings (I usually only use the server debugger).

I haven’t tried debugging within packages - someone more familiar will have to check that out.

Yes I’m using Windows. I just changed runtimeExecutable to null and it seems to be OK.

I’ve only started playing around with debugging in Visual Studio Code and I think I’ve got things working for both client-side and server-side debugging.

Even though Visual Studio Code says that some breakpoints are ignored because of a possible source map problem, they still work.

Ok and thanks for the prompt reply. The problem with packages seems to be that Meteor internally “repackages” the source code, and then the references on .map files become invalid. For example, for a source code stored on the folder: app_root/packages/my_package/server/my_code.js, meteor repackages this using the “meteor” package naming, which is really the name information from the Package.describe() method on the main package.js file.

This makes it impossible for any debugger to match the name stored on the .map file to the real name of the source code, even using localRoot, remoteRoot or outFiles parameters. I think the only way for making this work is if Meteor corrects the name reference in the generated .map files.

What do you think of this?

You know more than me at this point - I’d say file an issue in github

Here is Microsoft’s official guide to debug Meteor apps in Visual Studio Code:
Meteor debugging in VS Code (Node and Chrome)

I haven’t been able to get server-side Node debugging working myself though - it terminates after a few seconds. Client-side code debugging works fine. Has anyone had this problem and solved it?


The launch.json given by the OP works for me just fine. And I’m even using Typescript!

I have to say I followed that guide and it worked flawlessly for client and server.

What’s the story on Meteor 1.6 server debugging with Atom? Does anyone know a link to instructions?

Did not get it working either. Neither the recipe on Microsoft’s Github page nor the config posted above worked.

Something changed recently which makes the attach part work a bit weirder - I think you just have to press something in the VSCode floating controls. Once you do it once, it automatically connects the next time. They added a drop down too, so you can switch between the server and the client debuggers. It still works, but it’s less automatic.

Update: Oh I remember what I clicked - on the bottom of the VS Code window there is a button that says “auto attach” - I toggled that on, and then it started auto-attaching again.

Auto attach is definitely the way to go now folks. Just add the --inspect or --inspect-brk flag to your start script and turn on Auto Attach – there’s a command for it. It’s really painless now days. (Sometimes it tries to attach to Meteor’s build process which doesn’t work and interrupts your flow with a pop up which is really annoying but it’s just one more click :muscle:)


On MacOs here is a solution that worked for me: