Vs code server debugging with meteor 1.10?

help
1

I am running vs code and meteor 1.10.2 on ubuntu.
I can successfully pause at breakpoints for the server code using chrome devtools with this command from the system terminal:

MONGO_URL=mongodb://localhost:27017/h2iot5 meteor --settings settings-development.json --port 27016 --exclude-archs web.browser.legacy,web.cordova --inspect-brk

Yes, I use port 27016.
I have used the launch.json below in vs code (obtained from https://github.com/Microsoft/vscode-recipes/tree/master/meteor).

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "chrome",
            "request": "launch",
            "name": "Meteor: Chrome",
            "url": "http://localhost:3000",
            "webRoot": "${workspaceFolder}",
            "outputCapture": "std"
        },
        {
            "type": "node",
            "request": "launch",
            "name": "Meteor: Node",
            "runtimeExecutable": "npm",
            "runtimeArgs": ["run", "debug"],
            "outputCapture": "std",
            "port": 9229,
            "timeout": 30000
        }
    ],
    "compounds": [
        {
            "name": "Meteor: All",
            "configurations": ["Meteor: Node", "Meteor: Chrome"]
        }
    ]
}

I am unable to pause at the same breakpoints when I run this command from vs code’s terminal

MONGO_URL=mongodb://localhost:27017/h2iot5 meteor --settings settings-development.json --port 27016 --exclude-archs web.browser.legacy,web.cordova --inspect-brk

As a side note, the vs code checker complains that

"outputCapture": "std"

is not allowed

Any advice?

2

Hi, bumping this.

Does anybody do meteor server side debugging inside vs code?

3

Hi, I did but hadn’t done anything special. Just following a sample setup and it’s working fine

  {
            "type": "node",
            "request": "launch",
            "name": "Meteor: Node",
            "port": 9229,
            "timeout": 30000
        }

And run like this

meteor --port 3000 --settings settings.dev.json run --inspect
4

strange, to simplify things I created a new meteor project like so:

git clone https://github.com/meteor/todos -b react
cd todos/
meteor npm install
meteor update

In VS code I place a breakpoint at imports/startup/server/index.js line 5.
The I run the following inside the vs code terminal:

meteor --port 3000 run --inspect

which logs the following to the console (but does not stop at the breakpoint):

Debugger listening on ws://127.0.0.1:35297/aed03641-8036-4bc8-8d5f-bb8a0329e8be
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
[[[[[ ~/Desktop/temp/todos ]]]]]              

=> Started proxy.                             
                                              
Unable to resolve some modules:

  "@babel/runtime/helpers/createSuper" in /home/george/Desktop/temp/todos/imports/api/lists/lists.js (web.browser.legacy)
                                              
If you notice problems related to these missing modules, consider running:
                                              
  meteor npm install --save @babel/runtime    
                                              
                                              
Unable to resolve some modules:

  "@babel/runtime/helpers/createSuper" in /home/george/Desktop/temp/todos/imports/api/lists/lists.js (web.cordova)
                                              
If you notice problems related to these missing modules, consider running:
                                              
  meteor npm install --save @babel/runtime    
                                              
=> Started MongoDB.                           
W20200719-19:02:16.720(2)? (STDERR) Debugger listening on ws://127.0.0.1:9229/40c0794f-e25f-4ef9-b6b2-bc3e19b164e3
W20200719-19:02:16.906(2)? (STDERR) For help, see: https://nodejs.org/en/docs/inspector
W20200719-19:02:16.907(2)? (STDERR) Debugger attached.
W20200719-19:02:21.341(2)? (STDERR) Note: you are using a pure-JavaScript implementation of bcrypt.
W20200719-19:02:21.342(2)? (STDERR) While this implementation will work correctly, it is known to be
W20200719-19:02:21.342(2)? (STDERR) approximately three times slower than the native implementation.
W20200719-19:02:21.342(2)? (STDERR) In order to use the native implementation instead, run
W20200719-19:02:21.343(2)? (STDERR) 
W20200719-19:02:21.343(2)? (STDERR)   meteor npm install --save bcrypt
W20200719-19:02:21.344(2)? (STDERR) 
W20200719-19:02:21.344(2)? (STDERR) in the root directory of your application.
=> Started your app.

=> App running at: http://localhost:3000/

my vs code launch.json contains:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "chrome",
      "request": "launch",
      "name": "Meteor: Chrome",
      "url": "http://localhost:3000",
      "webRoot": "${workspaceFolder}",
      "outputCapture": "std"
    },
    {
      "type": "node",
      "request": "launch",
      "name": "Meteor: Node",
      "runtimeExecutable": "npm",
      "runtimeArgs": ["run", "debug"],
      "outputCapture": "std",
      "port": 9229,
      "timeout": 30000
    }
  ],
  "compounds": [
    {
      "name": "Meteor: All",
      "configurations": ["Meteor: Node", "Meteor: Chrome"]
    }
  ]
}
5

I’ve had these same issues for a while and haven’t been able to solve.

6

Does anyone know if this link is still valid after 2/3 years?

It did not work for me

7

Hi, who uses vs code debugging for meteor server side?

8

I debug both client side and server side code almost every day. It works very well. One thing that is important, is to make sure that you open vscode in the root of the meteor project, otherwise it won’t hit the breakpoint.

Here is my server config:

    {
      "type": "node",
      "request": "attach",
      "name": "server",
      "restart": true,
      "port": 9229
    },

restart: true is useful so that it re-attaches after rebuild. Run your meteor command with --inspect as well

9

Are you using TS? I’ve never been able to get breakpoint debugging to work with TS

10

Ok. I think I have a working setup:

The --inspect flag does not stop at my breakpoints, when I ran:

npm run meteorInspect

The relevant portion of my package.json was:

 "scripts": {
    "meteorInspect": "MONGO_URL=mongodb://localhost:27017/h2iot5 meteor --settings settings-development.json --port 27016 --exclude-archs web.browser.legacy,web.cordova --inspect",
  }

The --inspect-brk flag allows me to stop at my breakpoints, when I ran:

npm run meteorInspectBrk

The relevant portion of my package.json was:

 "scripts": {
    "meteorInspectBrk": "MONGO_URL=mongodb://localhost:27017/h2iot5 meteor --settings settings-development.json --port 27016 --exclude-archs web.browser.legacy,web.cordova --inspect-brk",
  }

My launch.json is

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Attach",
            "port": 9229,
            "request": "attach",
            "skipFiles": [
                "<node_internals>/**"
            ],
            "type": "pwa-node",
            "restart": true,
        },
    ]
}
11

Do you guys have any issues when stepping through code using the debugger? I set a breakpoint in my code, which works fine, but as I step through it will often jump out to various parts of Meteor’s source code located in the .meteor folder structure under my home directory.

I’ve tried a few options in launch.json - skipFiles, sourceMaps and smartStep, but just can’t get it to stop delving into Meteor’s own code base.

Although seeing the Meteor code execution is interesting it’s not helpful when trying to debug my own code lol :smile:

12

Another option is using step over, which stays in the same function, instead of step into on lines which calls Meteor’s code, though for me it works unreliably with code that uses fibers.

13

I’ve used vscode for typescript server debugging for over a year now except it suddenly stopped working a few weeks ago and now I need to use Webstorm instead.

It does work for a small sample project so I suspect it’s something in my code/setup. I have no idea what to do other than to hope that it suddenly starts working again.

14

Thanks @zodern. I have the same issue with async/await functions too.

I think the core problem is that the .meteor folder in the home directory is outside the VS Code workspace root so it won’t recognise any reference to those paths in skipFiles option within launch.json - I might have a dig around in the VS Code source if I find time too see how this all works internally in the event that may shed some further light on possible solutions.

15

It does appear that paths outside the workspace root are supported so my above suspicion was incorrect. Possibly might related to the + symbol used in the pathname, i.e:

/Users/xyz/.meteor/packages/promise/.0.11.2.1ixw4hn.8uhlk++os+web.browser+web.browser.legacy+web.cordova/npm/node_modules/meteor-promise/*

If I use the above path directly in skipFiles it does indeed skip the files that are related to Meteor promises module. Just need to find a way of getting it to blanket apply to the entire .meteor folder. Perhaps the + symbols are getting picked up as part of the “extglob” matching?!?

Looks like the VS Code debugger uses the minimatch npm package under the hood for processing the skipFiles paths (https://github.com/isaacs/minimatch)

16

I’ve found a solution @zodern… In this example path:

/Users/xyz/.meteor/packages/promise/.0.11.2.1ixw4hn.8uhlk++os+web.browser+web.browser.legacy+web.cordova/npm/node_modules/meteor-promise/promise_server.js

The first dot after /Users/xyz/.meteor/packages/promise/ is cause of the problem.

I pulled out the relevant glob matching code from the VS code debugger and knocked up a test case so I could modify the paths easily to see what would match the glob pattern and what wouldn’t. Removing this dot resulted in a positive match. I believe it’s due to the VS Code debugger not passing the dot option to the minimatch function.

As a result I’ve come up with the following launch.json which works perfectly - the key line to solve this particular issue is the last element of the skipFiles array:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Meteor",
      "port": 9229,
      "request": "attach",
      "skipFiles": [
        "<node_internals>/**/*.js",
        "${workspaceFolder}/node_modules/**/*.js",
        "${workspaceFolder}/.meteor/**/*.js",
        "/Users/xyz/.meteor/packages/*/.*/**/*.js"
      ],
      "type": "node",
      "restart": true
    }
  ]
}

Hope this helps anyone else frustrated by this issue! Happy debugging :smiley:

2 Likes
17

Excellent. Works great. Thanks for sharing!

18

It’s work for my project:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Meteor: Node",
      "type": "node",
      "request": "launch",
      "cwd": "${workspaceFolder}",
      "runtimeExecutable": "npm",
      "runtimeArgs": [
        "run-script",
        "start"
      ],
      "outputCapture": "std",
    },
    {
      "name": "Meteor: Chrome",
      "type": "chrome",
      "request": "launch",
      "url": "http://localhost:3000",
      "userDataDir": false,
      "webRoot": "${workspaceFolder}",
    },
  ],
  "compounds": [
    {
      "name": "Meteor: All",
      "configurations": [
        "Meteor: Node",
        "Meteor: Chrome"
      ]
    }
  ]
}

hope to help u :slight_smile: