Meteor 1.6 server debugging with VS Code

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:

I’ve just tried it and it works well.

Almost all posts in this thread are now obsolete. Maybe the thread should be closed. This new simple (and more reliable, it appears) way deserves a new thread, so I’ll make one now.

1 Like


Is it possible to debug the code in share path? Studio is installed in my system, but the meteor application is setup in different machine. When I try to run debug I am getting error as UNC path not allowed.

Please help.

Since it took my a while to get it running, I thought I’d share my setup, which is certainly not ideal:
I use windows with vscode. The whole dev stack is the linux version on WSL 1. I run vscode from Windows NOT from WSL because it causes tons of problems for me.
I simply run the meteor app normally from the wsl terminall (meteor run --inspect) and from vscode I have a simple config to connect the existing session:

    "version": "0.2.0",
    "configurations": [{
        "type": "node",
        "request": "attach",
        "name": "meteor debug - attach",
        "address": "",
        "port": 9229,
        "localRoot": "${workspaceFolder}",
        "remoteRoot": "${workspaceFolder}",
        "skipFiles": [
1 Like

You might want to consider WSL 2 (either in Insider Preview now or in the May update when it becomes available) - accessing the files in the subsystem has become a lot more sane.

You simply type code . in your project directory and Visual Studio Code will open the directory, install the WSL plugin and everything is dandy from then on out. You don’t have to mess around with symlinks, you don’t have to fear file corruption and so on and so forth.

If you then want to edit/move/delete/copy/… files in the WSL you can either do explorer.exe . in the directory of your choice or open the explorer and enter \\wsl$\WSL-name\home\username (which results in the same thing)

WSL-name would be Ubuntu-18.04 for me, for example, and username would be rhywden. It’d be different on your machine, of course.

1 Like

I’ve been waiting for WSL2 to release to try it out. I’m on Pop! OS as my main driver these days, so I don’t really need Windows. Honestly, I don’t miss Windows at all. Pop! OS is friggin’ awesome! Even gaming isn’t so bad with Lutris and Steam’s Proton (and all the native ports these days). There are only a few things I miss, and they are all from macOS, not Windows (Sketch and being able to test/publish iOS apps).

1 Like

I have tried this several times and for some reason the remote mode of vscode conflicts with npm and causes me tons of issues. Not sure if they can be fixed, but from googling the problem, obviously, a lot of people face similar issues without a clear fix.
I hope things are better when wsl2 is realesed.

1 Like

I’ve been unable to get it working on a mac setup in vscode and meteor lately because it can’t find the sourcemaps with Typescript.

I’ll give it a shot when I have the time - unless you do it first. The May update is out, after all :wink: