Vscode: How to debug Meteor app?

[spacenergy]

[isidorn]

Have you tried to debug it like any other node app?
If yes what issues have you run into?

[isidorn]

Closing until more info is provided

[george2giga]

Hi, trying to do the same, wondering what would be js file to use as entry point for the debugger (for node is app.js). any help would be much appreciated !

[isidorn]

Can you provide a minimum sample workspace for which we can try this out?

[george2giga]

Hi @isidorn , thanks for the quick reply.
Any meteor.js project should be fine, anyway I've uploaded the very basic sample provided by meteor when you create a new project https://github.com/george2giga/basic-sample, you can try this workspace.
Having the VS Code debugging working would be awesome.
Thanks

[isidorn]

Ok what seems to be somewhat working for me is the following:

• run your app by meteor debug
• have an attach request in your launch.json that will attach to the debug port that meteor gives you

@george2giga can you please try this?

[george2giga]

Thanks @isidorn , works a charm :)

[isidorn]

Glad it worked. Closing this

[winuxue]

Hi. I tried what you said, and vscode started debugging! but doesn't stop in my breakpoints. is there something that I'm missing?

[isidorn]

@winuxue please open a new issue with reproducable steps (possibly a small sample) so we could investigate this further.

[stefanofiorentino]

@isidorn check if port is really 5858, in my case was 5959
Debugger listening on port 5959

[jdnichollsc]

Any example using Meteor settings? For example with the following command:

meteor --settings settings.json --port 8890

Thanks in advance, Nicholls

[camstuart]

I can attach to the running process and set a breakpoint. But as soon as I change any server side code, meteor restarts (normal for meteor) and the debug process disconnects. then execution goes past my breakpoint because at that time, the debugger is not listening. I suspect this is what was happening @winuxue has anybody got this working correctly? a launch.json would be fantastic

[Exilz]

@camstuart I'm in the exact same situation here, I came to the same conclusion.
It's not far from being an awesome workflow !

[isidorn]

Ok seems to be no longer working looking at the comments -> reopening and assigning to april to investigate

[isidorn]

@camstuart @Exilz can you please try adding "restart": true to your launch configuration - which will notify the debug adapter to automatically reconnect to meteor when it restarts
If that does not work I can reopen this issue

[Exilz]

Thanks @isidorn , "restart": true prevents the debugger from disconnecting.
However, I can't get it to stop on my breakpoints.

If an exception is caught, the debugger will display it properly, but it's still ignoring breakpoints.
Not sure wether this is a bug or if I'm just missing something in my configuration

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "attach",
            "name": "Attach to meteor",
            "port": 5959,
            "restart": true,
            "sourceMaps": true
        }
    ]
}

[valdirSalgueiro]

im having the exact same bug @Exilz

[isidorn]

Assigning to @weinand as I am out of ideas
fyi @roblourens

[jesperordrup]

It works for me. I found that even though meteor tells me to use 5858 its really 5959.
I run

meteor debug

and meteor tells

To debug the server process using a graphical debugging interface,
visit this URL in your web browser:

http://localhost:8080/?port=5858

but this launch config works

      {
        "type": "node",
        "request": "attach",
        "name": "Attach to meteor 5959",
        "port": 5959,
        "restart": true,
        "sourceMaps": true
    }

[bcampardou]

You can use debugger; to stop in your code or set breakpoint in the compiled js application.

[MartinBucko]

Good news!
Meteor 1.6-beta.4 comes with Node v8.1.2. So it mean "protocol": "inspector" now works with VScode.

Update Meteor:
meteor update --release 1.6-beta.4

In launch.json:

...
{
            "type": "node",
            "request": "launch",
            "name": "Meteor Server",
            "cwd": "${workspaceRoot}/",
            "runtimeExecutable": "${workspaceRoot}/.meteor/local/dev_bundle/bin/npm",
            "restart": true,
            "timeout": 100000,
            "stopOnEntry":false,
            "runtimeArgs": [
                "run",
                "dev-debug"
            ],
            "sourceMaps": true,
            "protocol": "inspector",
            "port": 5959
        }
...

In package.json:

...
"scripts": {
    "start": "meteor run",
    "dev-debug": "meteor debug --debug-port 5959"
  }
...

And now it supports VScode breakpoints! :+1:

[isidorn]

@MartinBucko thanks for letting us know, closing this issue then

[chmac]

Just a little FYI for anyone finding this issue via Google as I have...

Meteor runs 2 node processes, one that "builds" your app and then one that gets killed and restarted on every "hot code reload". Let's call them parent and child. The parent process is the one that listens on port 3000, and it proxies connections to the child process. That's how hot code reload works. I believe that it's doing the same from 5858 to the child process which runs its debugger on 5959. However, it's been extremely flakey in all my tests.

I find that I get better results running meteor with the NODE_OPTIONS environment variable so I can start it like so:

NODE_OPTIONS='--debug' meteor run

This results in the child process being run like node --debug which causes its debugger to listen on 5858. Then I can connect to that with vscode. Thanks to this thread I've discovered the restart: true flag which means vscode reconnects to this child process (it gets killed on every code reload remember!).

I still can't get breakpoints to work though. Adding sourceMaps: true to my launch.json doesn't appear to work either. If I add a debugger; statement to my code, then vscode opens a "read-only inlined content from source map" version of my original file, rather than showing me the debugger in the original source file on disk. I'd guess that's the root cause of the breakpoints not working, vscode doesn't know how to map the files on disk to the es5 code that the child meteor process actually runs. If we could solve that, I'd guess that breakpoints would work.

[aadamsx]

Why has this been closed? it still doesn't work for me on 1.5.1 (the current official, non-beta, release).

[ntziolis]

I'd guess that's the root cause of the breakpoints not working, vscode doesn't know how to map the files on disk to the es5 code that the child meteor process actually runs. If we could solve that, I'd guess that breakpoints would work.

Same here, can someone that already runs Meteor 1.6 confirm that the breakpoint issue is solved as well? Not just the debugger starting but that breakpoints are actually properly hit? Otherwise I would reopen this case.

[aadamsx]

We need proper, comprehensive, instructions on how to set this up with Meteor -- to make sure some issues are not just because of configuration or process -- and then whatever falls out of that should be fixed.

I've followed and added most-all configuration instructions, yet I still cannot get things working with breakpoints -- heck I can't even tell if its working at all. For now I'll have to stick with using the console/node-inspector for debugging sever side, and not get the full VSCode experiance I believe MS intended.

NOTE: I'm on Meteor 1.5.1, and VSCode 1.15.1

[Miniwe]

My way:
1: launch.json

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Meteor Attach",
      "type": "node",
      "request": "attach",
      "port": 5858,
      "address": "localhost",

      "processId": "${command:PickProcess}",
      "smartStep": true,
      "trace": false,
      "restart": true,

      "timeout": 20000,
      "sourceMaps": true,
      "outFiles": [
        "${workspaceRoot}/.meteor/local/build/programs/web.browser/app/app.js",
        "${workspaceRoot}/.meteor/local/build/programs/server/app/app.js"
      ]
    }
  ]
}

1. Start Meteor
2. run debug in vcode
3. select meteor process
4. open build/programs/server/app/app.js and add breakpoint in this file
5. when program will reach breackpoint VCode will open server file for read only generated from sourcemap same as original file from app
6. in this file we can add breakpoints and variables in watch
7. for client only debugger or work over chrome dev tools

[MartinBucko]

My previously mentioned config works with meteor 1.6-beta.15 (node v8.2.1, correct version for node inspector) but not with Meteor 1.5 (lower node version, don't support inspector!)...

[jesperordrup]

@Miniwe Which versions (Meteor, nodejs, ...) is this for? Thanks

[weinand]

@Miniwe Is it really necessary to select the meteor process with the process picker in the launch config from above? If meteor is launched in debug mode, then specifying the port is all you need to attach the debugger. Attaching by processId (or with the picker) is only useful if meteor was not started in debug mode.

The "outfiles" attributes accepts glob patterns, so you can just set it to this:

      "outFiles": [
        "${workspaceRoot}/.meteor/**/*.js",
      ]

This selects all *.js files under the .meteor directory (on any folder level).

[Miniwe]

Meteor 1.5.1
node v7.8.0
Screenshot

[roblourens]

This should work as long as you're using a Meteor version that supports the Inspector protocol. I'm not super familiar with Meteor but from https://github.com/Microsoft/vscode/issues/256#issuecomment-312260958 it sounds like this will only work with Meteor 1.6+. This is because the inspector debug adapter supports the path mapping needed to fix Meteor's weird sourcemap paths, and fixes the default one automatically - https://github.com/Microsoft/vscode-node-debug2/blob/master/src/nodeDebugAdapter.ts#L26

[weinand]

We should create a Meteor recipe!
-> https://github.com/weinand/vscode-recipes/issues/21

[ntziolis]

Thank you @Miniwe, I wasn't expecting to have to set breakpoints outside of my actual source, I guess I#m spoiled by now. So from this thread and all others this is my current conclusion:

Meteor pre 1.6
Debugging is possible, BUT only by setting breakpoints in the output that Meteor generates. NOT in your actual source files. This is better then no debugging at all, but not being able to fix issues write where you find them is not optimal + setup is complex

Post 1.6
Proper debugging with breakpoints in actual source files.

... preying for 1.6 to arrive soon :)

[MartinBucko]

@Miniwe Meteor 1.5.1 have node version 4.8.4 !
Here is example how to get correct node version under meteor:

vertest ➜ meteor --version
Meteor 1.5.1
vertest ➜ meteor node --version
v4.8.4
vertest ➜ meteor npm --version
4.6.1