Debugger and runTimeArgs order

[danielepolencic]

• VSCode Version: 1.7.2
• OS Version: macos 10.12.1

I don't have nodejs installed locally on my machine, but I'm using the official docker image to run the typescript. I tried to setup VS Code to launch the docker image but the --debug-brk flag is injected before any of the arguments. Is there any way I could control the order of the arguments?

Steps to Reproduce:

1. Use the following launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Launch Program",
      "program": "${workspaceRoot}/index.ts",
      "cwd": "${workspaceRoot}",
      "outFiles": [],
      "sourceMaps": true,
      "env": {
        "NODE_ENV": "development"
      },
      "outDir": "${workspaceRoot}/bin",
      "runtimeExecutable": "docker",
      "runtimeArgs": ["run", "-ti", "node:6.9.1"]
    }
  ]
}

2. Run the program in debug mode.

The console prints:

docker --debug-brk=35420 run -ti node:6.9.1 bin/index.js 
flag provided but not defined: --debug-brk
See 'docker --help'.

To run the application in docker that line should read instead:

docker run -ti node:6.9.1 bin/index.js --debug-brk=35420

[weinand]

@danielepolencic you can avoid that VS Code passes a --debug-brk=nnnnn to the runtime by managing the debug port manually. Just set a "port": 55555 attribute in your launch config and add a corresponding runtime argument "--debug-brk=55555".

And please use outFiles correctly instead of the deprecated outDir.

This should work:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Launch Program",
      "program": "${workspaceRoot}/index.ts",
      "cwd": "${workspaceRoot}",
      "outFiles": [ "${workspaceRoot}/bin/**/*.js" ],
      "sourceMaps": true,
      "env": {
        "NODE_ENV": "development"
      },
      "port": 35420,
      "runtimeExecutable": "docker",
      "runtimeArgs": ["run", "-ti", "node:6.9.1", "--debug-brk=35420" ]
    }
  ]
}

[papandreou]

@weinand, sorry for commenting on an old issue, but I just ran into a similar problem while trying to get VS Code to collaborate with nvm, and I've come to believe that this issue shouldn't have been closed.

I got it to work using your workaround:

{
  "version": "0.2.0",
  "configurations": [
    {
      "protocol": "inspector",
      "type": "node",
      "request": "launch",
      "name": "Mocha Tests",
      "program": "${workspaceFolder}/node_modules/mocha/bin/_mocha",
      // Hardwire the port to prevent VS from injecting --inspect-brk=... before the runtimeArgs:
      // https://github.com/Microsoft/vscode/issues/16173#issuecomment-263496120
      "port": 49534,
      "args": [
        "-u", "tdd",
        "--timeout", "999999",
        // ...
        "tests/**/*.js"
      ],
      "internalConsoleOptions": "openOnSessionStart",
      "runtimeExecutable": "${env:NVM_DIR}/nvm-exec",
      "runtimeArgs": [
        "node",
        "--inspect-brk=49534" // Has to match the "port" config above
      ]
    }
  ]
}

It would have been nicer if I could just have omitted the "port": 49534 config and the hardcoded --inspect-brk=49534, but if I do that, a non-functional command line is generated, similar to the Docker problem mentioned above:

/Users/andreaslind/.nvm/nvm-exec --inspect=41943 --debug-brk node node_modules/mocha/bin/_mocha -u tdd --timeout 999999 ... tests/**/*.js 

... the problem being that node (from runtimeArgs) should come right after /Users/andreaslind/.nvm/nvm-exec.

It seems unintuitive that Code would inject that before the runtimeArgs, and now we have two examples of it causing undesirable results. Don't you agree that it seems like an actual bug?

[auchenberg]

@papandreou Wouldn't you setting your default Node version via NVM solve things and simplify the configuration? https://eric.blog/2016/08/23/set-default-node-version-with-nvm/

[papandreou]

Hey @auchenberg, long time no see :). I have specified the default alias, but I’m working on several projects, and they’re not all ready to upgrade node at the same time. I think it’s very common for applications (rather than libs) to be tied to a single major version of node at any given time. Upgrading will usually require you to upgrade several dependencies, some of which won’t be backwards compatible with the old node version. Also, you’ll quickly start to use new language features that weren’t available in the old version.

Because of that, it’s practical to have local .nvmrc files version controlled with the individual projects. For the lack of something better, .nvmrc checked in at the root seems to have become the standard way of declaring the node version, as you can also tell from the number of people weighing in here and here

As another example, Travis supports .nvmrc directly: https://docs.travis-ci.com/user/languages/javascript-with-nodejs/#Specifying-Node.js-versions-using-.nvmrc

[weinand]

@roblourens For the legacy protocol I'm now adding the --debug... flag after all runtimeArgs (instead of before). You might want to do the same for the --inspect... flag for the inspector protocol.

[roblourens]

Done!

[papandreou]

Wow, thanks, guys :)

[weinand]

Verification:
create a launch config that has both runtime args and program args, then verify that the "--debug" or "--inspect" argument comes at the end of the runtime args before the program args.
You can see the full command line in the debug console.
Verify this for both protocols.