Hi,

I'm testing remote debugging with typescrypt. I'm using the example node-express-typescrypt from the repo.

The issue I have is that when attaching a remote debug session and setting a breakpoint in the .ts file the breakpoint moves up to other line, and when VSCode starts debugging it stops in a .js file (not the real .js file in the folder but a 'content streamed from remote node'). This is the launch config:

        {
            "request": "attach",
            "name": "Attach to REMOTE running instance",
            "type": "node",
            "address": "192.168.47.22",
            "localRoot": "${workspaceRoot}",
            "remoteRoot": "/var/apps/nodejs/node-express-typescript",
            "sourceMaps": true,
            "outDir": "${workspaceRoot}/src",
            // Port to attach to, must match port in gulpfile.js
            "port": 5858
        }

I've observed that if I attach to a localhost debug session it works (stops in the .ts file), but only when not adding the remoteRoot property. If I add it (although not needed, I guess), the problem arises, it stops in the .js streamed content.

        {
            "request": "attach",
            "name": "Attach LOCALHOST to running instance",
            "type": "node",
            "address": "localhost",
            "localRoot": "${workspaceRoot}",
            //"remoteRoot": "${workspaceRoot}", // if uncommented, then it fails (goes to .js streamed content)
            "sourceMaps": true,
            "outDir": "${workspaceRoot}/src",
            // Port to attach to, must match port in gulpfile.js
            "port": 5858
        }   

Note: Local machine is Windows 10, Remote machine is Ubuntu 14.04, sharing a folder in windows 10 for the source code.

Currently we have function breakpoint support in VSCode ui, however function breakpoints are missing in the protocl

see below

The latest (and only) tag is 0.10.2, but the current release is at 0.10.4

When building vscode from source, manual installation of vscode-node-debug is required for parity with the vscode release version. The current vscode release uses vscode-node-debug 0.10.4. If you're trying to replicate the same version that ships in the vscode release build, it's trickier than it needs to be, because:

1. There is no release tag, and
2. Changes that follow the 0.10.4 release continue to use the 0.10.4 version string in the package.json, instead of something like 0.10.5-pre

Currently they only display map or set, they should work like objects / arrays. For Set, basically what you get for Array.from(set).

node 5.x seems to to support external addresses for its debug port. We should add support for this.

From @BleyChen on December 2, 2015 9:10

It throw “source is not available” error when I imported “http” module and use one API in my code ,anyone know what’s the problem?

Code :
http.request('http://www.google.com', function(response) {
console.log(response.statusMessage) });
plugin sample code(http://mediasvc1nxn1n47jdwb5.blob.core.windows.net/guided-tours/testIntellisenseJavascript.zip)

Steps for repro this problem:

1. Download the source and open it in VSCode
2. Run it and you will see an vscode instance
3. Change the language mode in “untitled-1” from “Plain Text” to “Javascript”
   
   4.Type an character and it will trigger the method “”,then you will see the error.
   

Copied from original issue: microsoft/vscode#902

I'm not entirely sure if I should raise the ticket here of the vscode repository.
As the title says breakpoints no longer work after the update but if I put a debugger statement in then it will correctly show the source code and step through but attempting to add any breakpoints fails.

Edit turns out it's on awaited results that it's having an issue.

Start debugging, open an internal module (e.g module.js) and put a try to put a breakpoint in the internal module -> node debug crashes with the following error:

I am using the latest node debug coming with vscode 0579a68ac2aab037d47b8fefc048719a9d2f66d2

/Users/isidor/.code-oss-build-dev/extensions/node-debug/out/node/nodeDebug.js:905
        var escPath = path.replace(/([/\\.?*()^${}|[\]])/g, '\\$1');
                          ^
TypeError: Cannot read property 'replace' of null
    at NodeDebugSession._pathToRegexp (/Users/isidor/.code-oss-build-dev/extensions/node-debug/out/node/nodeDebug.js:905:27)
    at /Users/isidor/.code-oss-build-dev/extensions/node-debug/out/node/nodeDebug.js:726:41
    at NodeV8Protocol.internalDispatch (/Users/isidor/.code-oss-build-dev/extensions/node-debug/out/node/nodeV8Protocol.js:169:21)
    at NodeV8Protocol.execute (/Users/isidor/.code-oss-build-dev/extensions/node-debug/out/node/nodeV8Protocol.js:215:26)
    at Socket.<anonymous> (/Users/isidor/.code-oss-build-dev/extensions/node-debug/out/node/nodeV8Protocol.js:61:60)
    at emitOne (events.js:77:13)
    at Socket.emit (events.js:169:7)
    at readableAddChunk (_stream_readable.js:146:16)
    at Socket.Readable.push (_stream_readable.js:110:10)
    at TCP.onread (net.js:523:20)

STR

1. Download a source drop of vscode-node-debug (directory containing source
   code, but isn't a git repo containing version history)
2. Try to npm install from that directory

Expected results

It works.

Actual results

It fails:

colby@ruta-corsica:~/.vscode-oss-dev/extensions/vscode-node-debug$ npm install
npm WARN deprecated [email protected]: lodash@<3.0.0 is no longer maintained. Upgrade to lodash@^4.0.0.
npm WARN deprecated [email protected]: lodash@<3.0.0 is no longer maintained. Upgrade to lodash@^4.0.0.
/
> [email protected] prepublish /home/colby/.vscode-oss-dev/extensions/vscode-node-debug
> gulp build

/home/colby/.vscode-oss-dev/extensions/vscode-node-debug/node_modules/git-rev-sync/index.js:46
    throw new Error('[git-rev-sync] no git repository found');
    ^

Error: [git-rev-sync] no git repository found
    at _getGitDirectory (/home/colby/.vscode-oss-dev/extensions/vscode-node-debug/node_modules/git-rev-sync/index.js:46:11)
    at _getGitDirectory (/home/colby/.vscode-oss-dev/extensions/vscode-node-debug/node_modules/git-rev-sync/index.js:49:10)
    at _getGitDirectory (/home/colby/.vscode-oss-dev/extensions/vscode-node-debug/node_modules/git-rev-sync/index.js:49:10)
    at _getGitDirectory (/home/colby/.vscode-oss-dev/extensions/vscode-node-debug/node_modules/git-rev-sync/index.js:49:10)
    at _getGitDirectory (/home/colby/.vscode-oss-dev/extensions/vscode-node-debug/node_modules/git-rev-sync/index.js:49:10)
    at _getGitDirectory (/home/colby/.vscode-oss-dev/extensions/vscode-node-debug/node_modules/git-rev-sync/index.js:49:10)
    at _getGitDirectory (/home/colby/.vscode-oss-dev/extensions/vscode-node-debug/node_modules/git-rev-sync/index.js:49:10)
    at branch (/home/colby/.vscode-oss-dev/extensions/vscode-node-debug/node_modules/git-rev-sync/index.js:53:16)
    at long (/home/colby/.vscode-oss-dev/extensions/vscode-node-debug/node_modules/git-rev-sync/index.js:65:11)
    at Object.short (/home/colby/.vscode-oss-dev/extensions/vscode-node-debug/node_modules/git-rev-sync/index.js:92:10)

npm ERR! Linux 3.13.0-77-generic
npm ERR! argv "/home/colby/Downloads/node-v4.2.2-linux-x64/bin/node" "/home/colby/bin/npm" "install"
npm ERR! node v4.2.2
npm ERR! npm  v2.9.1
npm ERR! code ELIFECYCLE
npm ERR! [email protected] prepublish: `gulp build`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] prepublish script 'gulp build'.
npm ERR! This is most likely a problem with the node-debug package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     gulp build
npm ERR! You can get their info via:
npm ERR!     npm owner ls node-debug
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /home/colby/.vscode-oss-dev/extensions/vscode-node-debug/npm-debug.log

Temporary workaround

1. Replace the source drop with live clone of the git repo
2. git checkout the release corresponding to the source drop
3. Run npm install

Inspecting large data structures results in slowness (unresponsiveness) issues in node >= 3.x.

The problem is the node debugger protocol which does not provide a way to access arrays or dicts in chunks. Always the full thing travels over the wire. A particular nasty issue is that local variables are included in the stack frame object even if nobody requested them. A consequence is that stepping through code with large arrays, Buffers, or dicts in local variables results in slowness and timeouts.

Up to node 0.12.x we did some code injection into the debugger to work around these issues and they were quite effective. If possible, just try to use node 0.12.9 and you will notice the difference.

For node 4.x and 5.x we haven't figured out how to do the same trick, but we are working on it.

Make sure that non-JavaScript breakpoints without source maps are reported back as unverified.

From @karsep5 on November 26, 2015 5:29

When stepping through code while debugging node application, in addition to unresponsiveness every now and then, my Macbook gets really hot with the CPU fan going supersonic. Seems to occur only when trying to step through the code. Running the program when it is just attached does not seem to have problems.

Copied from original issue: microsoft/vscode#688

VS Code is unable to resolve a source file for a source map when the entry in the "sources" array of the source map starts with "file://".

For example, if tsc.js.map contains the source "file:///C:/dev/TypeScript/src/compiler/core.ts", when attempting to debug tsc.js I get an error from VS Code that it cannot load the file "C:/dev/TypeScript/built/local/file/C/dev/TypeScript/src/compiler/core.ts".

When running the snippet below then there is no chunking of the value and you get a 'large data structure' timeout.

var t = {};
for (var i = 0; i < 10000; i++) {
t[i] = i;
}

Looking at the response I am getting from the node adapter I never get adjusted breakpoint lines any more. I always get back the original lines I sent. I know this was working ~ 3 weeks ago

Here's a snippet for which I can repro. Putting breakpoints on lines 1, 3, 5 I would expect they jump, but they do not.

try {
    throw Error("I am an error, hi there!");
} catch (e) {
    console.log(e);
}
var i = 5;

From @sangrambal on December 2, 2015 0:42

When creating Helloworld extension , got the following error message after F5
cannot connect to runtime process (timeout after 3000ms)

Copied from original issue: microsoft/vscode#893

I'm trying to use vscode node debug/launch settings on a simple web app ng2 application, based on https://angular.io/docs/ts/latest/quickstart.html, where the web server that is launched for debugging is the https://www.npmjs.com/package/lite-server, that builds on top of https://www.browsersync.io/ package.

I can get vscode to successfully launch the node package provided web server but it is not stopping on any of my typescript soft breakpoints.

This can be repro’d by cloning https://github.com/myusrn/vscng2qs | executing "npm install" to restore modules | opening in vscode | building typescript using ctrl+shift+b [ or "npm run tsc" | setting a few break points in app/main.ts and/or app.component.ts | then selecting vscode debug "Launch lite-server" option.

I have a project based on https://github.com/DaftMonk/generator-angular-fullstack that I was able to debug just fine with the following configuration:

{
"version": "0.2.0",
"configurations": [
    {
        "name": "NodeJS Attach",
        "type": "node",
        "request": "attach",
        "port": 5858
    },
    {
        "name": "Chrome Launch",
        "type":"chrome",
        "request": "launch",
        "url": "http://localhost:9000/",
        "sourceMaps": true,
        "webRoot": ".tmp"
    },
    {
        "name": "Chrome Attach",
        "type": "chrome",
        "request": "attach",
        "port": 9222,
        "sourceMaps": true,
        "webRoot": ".tmp"
    }
]
}

But since a few releases ago, the attach functionality doesn't work anymore. If I launch with an initial breakpoint the debugger does kick in but doesn't hit any other breakpoints (even if I set them after the initial breakpoint).

Ideally, I should be able to attach to the debugger running on 5858 at any time. Am I missing something here? Happy to share any details needed.

From @m90 on November 18, 2015 16:44

I'm trying to attach the Visual Studio Code debugger to a node.js app that is running inside a Docker container.

The app starts like:

node --debug-brk app.js

My docker-compose.yml exposes the port for attaching:

app:
  build: .
  working_dir: /code
  volumes:
    - .:/code
  command: npm run debug
  ports:
    - "3004:3000"
    - "5858:5858"

launch.json is pretty simple:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Docker",
            "type": "node",
            "request": "attach",
            "port": 5858
        }
    ]
}

Now, when I start the application and attach the debugger this will correctly connect (I can see the values flashing in the debugger UI already), but then it will stop, telling me the following:

Error opening 'app.js' (File not found: /code/app.js).

Is there any way to fix this path offset? Should one handle this scenario completely different?

Copied from original issue: microsoft/vscode#59

From @flyingcodes on December 16, 2015 7:41

var fun1 = new Function("return 1 + 2; // in fun1"); // break point
var fun2 = new Function("return 3 + 4; // in fun2");
var r = fun1(); // the folow will step in code of fun1 if step in at this line
r = fun2(); // will step in code of fun1 if step in at above line, else step in code in fun2
console.info("r = " + r); // but the result is valid

Copied from original issue: microsoft/vscode#1364

VSCode try to set a breakpoint in a node internal module. Notice the error in the console that the Source is not sent, even though it is part of the brekapoints request.

From @jimthedev on November 19, 2015 21:52

I think I've outlined this pretty well here:

http://stackoverflow.com/questions/33811221/visual-studio-code-extension-host-timeout-during-debugging

Basically the problem is that when I actually try to debug the extension, those based on Typescript just result in timeouts of both sides of the debugging workflow.

In Javascript everything seems to work properly. I'm not sure if this is just a race condition based on the fact that the typescript must be compiled and thus pushes it outside the 3000ms timeout that Code seems to be willing to wait.

Copied from original issue: microsoft/vscode-generator-code#15

Code looks ike this:

function* getFiles() {
    let urls = [].slice.call(arguments);

    let results = yield urls.map(function(url){
        return new Promise((resolve, reject) => {
            setTimeout(() => {
                resolve("new value");
            }, 1000);
        });
    });
    results.forEach((val) => { console.log(val) });
}

let iterator = getFiles("file1", "file2", "file3");
//iterator is undefined
Promise.all(iterator.next().value).then(function(results){
    iterator.next(results);
});

If I set debugger after I created an generator's iterator and place this variable into watch section (or just hover it with mouse pointer) I'll see that variable "iterator" has "undefined" value.

You have some code like this:
if (mapPath.indexOf("data:application/json;base64,") >= 0) {

but they may not contain that exact string. Here's another vaild inlined sourcemap prefix:
data:application/json;charset:utf-8;base64,

So I changed this code to search for the last ,

Hi! I just installed Code and first impressions are very good (^_^)

A problem I ran into is that stopping the process with Code uses the KILL (9) signal in terminateProcess.sh which kills the process immediately. My application listens for SIGINT/SIGTERM and stops servers and queues gracefully, but SIGKILL cannot be listened to so I can't do this when using the debugger. Would it be possible/easy to add an option to define how the process is killed or would it cause issues with the debugger if the process does not immediately die when the stop button is pressed?

For context, this is my code that handles exiting the process

var server = require('../lib/server') // an HTTP server
server.listen(8000)
process.on('SIGINT', function() {
  console.log('Got SIGINT.');
  server.close() //keeps the process alive until all connections are closed
});

From @martellaj on December 9, 2015 20:59

Assume there's a file app.js in directory Foo. If in my launch.json file, I specify foo/app.js as the program, the debugger will run, but none of my breakpoints will get hit. However, if I give it the actual casing of the path, Foo/app.js, the debugger runs and breakpoints will get hit.

I think it should be all or nothing here. As in, if correct casing is required for breakpoints to get hit, then correct casing should be required for the debugger to work at all. Or vice versa (and preferably), if correct casing isn't required to run the debugger, than correct casing shouldn't be required for breakpoints to get hit.

Copied from original issue: microsoft/vscode#1149

Type script code:

import * as request from "request";

let options = {
    url: "https://upload.wikimedia.org/wikipedia/commons/3/3d/LARGE_elevation.jpg",
    method: "GET",
    encoding: null
};

request(options, (err, response, body) => {
    console.log("done");
});

console.log("downloading...");

Program works ok from console. Now set breakpoints on request(...) and on console.log("done"); line. Debugger will stop correctly on request line but when you press F5, you will only get 'Paused on breakpoint.' in call stack and no other clue where debugger has stopped. If you press F5 again you get error 'request 'continue': request 'continue' was cancelled because node is unresponsive'.

enabling "Stop on Entry" in launch config doesn't work for node debugging.

I just tried to implement externalConsole for my PHP debugger and noticed how hard it is cross-platform and with keeping the console open. In the end, I just copied the excellent helper classes from here into my project. I think a lot of projects would benefit from this. Also, it is nice to have a uniform look for externalConsole (like the title "VS Code debug console").

We have an extension which depends on this one, and we've just found out that in the upcoming release of vscode, since the publisher name has changed we are going to be broken: microsoft/vscode-react-native#155

What do you propose as the best solution? If we change to taking a dependency on the new publisher+extension name, will that work in both newer and older versions of vscode, or will we need to make a breaking change and not support previous versions?

@weinand

Can this addon also support debugging Javascript with the Firefox browser?

I found some documentation about remote debugging here

From @stevencl on November 16, 2015 15:11

In a simple node app, I step through a loop in the debugger. Before exiting the loop, I press the stop button

I expect the program to stop executing right at that point but it appears to continue executing due to the fact that the console.log statement is executed (highlighted below) and the value of the string being output looks like the loop continued to execute even after pressing stop:

Copied from original issue: microsoft/vscode#32

From @djabraham on December 19, 2015 1:37

First, I want to thank Microsoft for VSCode. It's truly wonderful to use both this powerful editor and TypeScript together, with everything else the open-source community has to offer.

I have issues with debugging when node.js MUST run in a docker container, in order to connect to other containers and so forth. I know that remote debugging isn't supported yet, but it may actually be easy to fix a couple of obstacles that I encountered, since I was able to find work arounds myself. The major issues with debugging node.js in a locally hosted docker container that I saw were as follows:

1. VSCode obtains and then monitors the node process PID, then shuts down the debugger after several seconds if it notices that the PID isn't actually running. This is not idea, when the process is running in a separate container, so it would be nice if that requirement were optional.

2. VSCode uses absolute paths to the source code. This is not ideal if the source code's location on the host is different than that of the docker container. Containers use different mappings all the time, so relative path would be a much better approach.

I was able to work around the first issue by creating a small proxy that is run on the host, along side VSCode. All the proxy does if forward packets back and fort between two ports, for the most part. But when it sees the PID packet being returned from node.js, it substitutes its own PID. This is in order to prevent VSCode from exiting prematurely. The source for the proxy is here, by the way:

https://gist.github.com/djabraham/19af4ea435dd94418af0

I was able to work around the second issue by bind-mounting the source code into the same path on the host as within the docker container. This could be a major pain for users on OSX, because it required downloading and compiling bind, along with other utilities, and performing the mount. And while it works on a MAC; however, I am not sure how to do something similar on Windows.

Thanks again for all the great tooling!

Copied from original issue: microsoft/vscode-debugadapter-node#2

Objects that have properties with getters / setters incorrectly display the value of the properties as 'undefined'. (See first attached screenshot, 'object3.myprop'). This leads to confusing debugging sessions. In contrast, the Chrome debugger makes it clear that there is a getter which would be invoked. (See second screenshot).

Suprisingly, object properties that have a numeric name will automatically invoke the getter function and display its value (First attached screenshot, 'object4.4').

Note that evaluating the property will yield the value '3' correctly in both cases.

The test code is:

var object3 = {};
Object.defineProperty(object3, "myprop", {
enumerable: true,
configurable: true,
get: function() { return 3; },
set: function(x) { }
});

And for the numeric property:

var object4 = {};
Object.defineProperty(object4, "4", {
enumerable: true,
configurable: true,
get: function() { return 3; },
set: function(x) { }
});

Is it possible to influence how properties with a getter are displayed in the debugger? Or to at least avoid that they are displayed as just 'undefined'.

Thanks in advance!

Currently when debugging node, evaluating 'global' gives a nice expandable object, but 'console.log(global)' is a giant string. An OutputEvent should be able to take a variableReference like an evaluate response.

Giving this to you @weinand to investigate and if we want to introduce it give it back gto me so I implement it on the vscode side.
Requested by @roblourens

If a source map is not resolved correctly for a given file when debugging node, VSCode shows "Source is not available."

Is it possible to just show the actual code being executed in these situations?

I posted a stack overflow here.

I'm trying to use the debugger in vscode and doing some server side rendering. I had my launch file as such:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch",
            "type": "node",
            "request": "launch",
            "program": "${workspaceRoot}/lib/server/server.js",
            "stopOnEntry": false,
            "args": [],
            "cwd": "${workspaceRoot}",
            "env": {
                "NODE_ENV": "development"
            },
            "externalConsole": false,
            "sourceMaps": false,
            "outDir": null
        },
        {
            "name": "Attach",
            "type": "node",
            "request": "attach",
            "port": 8080,
            "sourceMaps": false,
            "outDir": null,
            "localRoot": "${workspaceRoot}",
            "remoteRoot": null
        }
    ]
}

and it would fail silently after spitting out a warning regarding content editable. I switched it to attach it to a process running in my terminal, and it looks like this:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Attach to Node",
            "type": "node",
            "request": "attach",
            "port": 5858
        }
    ]
}

Then I ran node --debug-brk lib/server/server.js and started my debugger. It successfully stopped at the first line. I tried to open the same page that had failed before and got the contenteditable mixed with react warning and then the console printed Segmentation fault: 11 and the application stopped running. Simply running my application in the terminal (node lib/server/server.js) returns no errors other than the warning about mixing contenteditable and react.

From @nakosung on December 20, 2015 6:10

vscode seems to handle 'drive-letter' in both small letter and capital letter, this makes some conflict while dealing with breakpoints.

I would like to PR for this bug fix, but I don't know where to contribute.

Copied from original issue: microsoft/vscode#1500

From @cdaringe on December 2, 2015 0:38

Hello:

Often when I debug a node.js app, I want to toggle break on "All Exceptions". In node, that means on every require statement it breaks during a stat check.

In most of my apps, that's quite a few require statements, and thus quite a few breaks! The below should look familiar to other nodejs debugging devs! Even if a first pass as the feature was "Blackbox node internals", that would be a huge help!

If you'd like to pass some pointers my way, I'd consider working a PR for the basic ignore?

Copied from original issue: microsoft/vscode#892

From @rbuckton on November 18, 2015 19:37

I’m seeing an issue in VS Code when debugging a TypeScript file with Source Maps that uses TypeScript Async Functions. When I set a breakpoint on the first line of the function body, the breakpoint moves to the first executable line following the end of the function body. I’m trying to determine if this is an issue with TypeScript’s SourceMap output, with VS Code, or with the version of V8 used by VS Code. I’ve tested the same scenario in Chrome Canary and breakpoints seem to bind correctly, which leads me to believe the issue may not be with TypeScript.

After further discussion, it looks like the issue is in the node-debug extension. Changing the default from Bias.GREATEST_LOWER_BOUND to Bias.LEAST_UPPER_BOUND seems to solve the problem.

CC: @weinand

Copied from original issue: microsoft/vscode#91

Hi,

I'm testing the new remote debugging funcionality in the VSC January release and it's not working for me.

When adding the new property 'address' it only works for a 'localhost' .But I also have an Ubuntu VirtualBox and I can't make it start debugging. Host machine is Windows 10. I'm using node v5.6.0.

My launch configuration is next:

        {
            "request": "attach",
            "name": "Attach to running instance",
            "type": "node",
            "address": "192.168.47.22", // guest machine
            "localRoot": "C:/desarrollo/testing/nodejs/node-express-javascript",
            "remoteRoot": "/var/apps/nodejs/node-express-javascript",
            "port": 5858
        }

In host machine I have a shared folder "C:/desarrollo/testing/nodejs" with the Ubuntu guest machine in order to share the code. I have set up both localRoot and remoteRoot properties accordingly.

I know VS Code is connecting to the remote debug session in guest machine because I run: node --debug-brk bin/www and VS Code stops in the first line.

Update: Some more info when testing other options:

I have installed and started node-inspector in the Ubuntu virtualbox and set a breakpoint in the inspector (web page in the host http://192.168.47.22:8080/?ws=192.168.47.22:8080&port=5858 ). Now the breakpoint is hit in node inspector but (surprinsingly) also in VSCode. So somehow the properties in the launch configuration are ok but, I guess, when setting the breakpoint in VSCode is not working properly.

In pre 0.9.1 versions I had the following configuration and it worked fine, I could set breakpoints in the VSCode and they were hit when tests executed. After the 0.9.1 update the tests are executed however breakpoints are not hit anymore.

It could be awesome if this capability returned again.

As for alternatives, I see that I could switch to using new chrome-debug extension, and run tests in a chrome window, but this is not ideal. Keeping everything in the console output windows makes things clearer.

Karma v0.13.14
PhantomJS v1.9.18

launch.json:

{
    "name": "Run Karma tests",
    "type": "node",
    "program": "<path>/node_modules/karma/bin/karma",
    "args": [
        "start",
        "<path>/karma.conf.js"
    ],
    "runtimeArgs": [
        "--nolazy"
    ],
    "stopOnEntry": false,
    "sourceMaps": false
},

karma.conf.js:

module.exports = function(config) {
  config.set({
    frameworks: ['jasmine'],
    files: [...],
    preprocessors: {
      'src/**/*.jade': 'ng-jade2js',
    },
    ngHtml2JsPreprocessor: {
      stripPrefix: 'src/'
    },
    ngJade2JsPreprocessor: {
      stripPrefix: 'src/',
      moduleName: 'templates'
    },
    exclude: [],
    port: 9876,
    logLevel: config.LOG_INFO,
    autoWatch: true,
    reporters: ['mocha', 'junit'],
    junitReporter: {
      outputDir: 'tmp/test_results',
      outputFile: 'webtests.xml', 
      suite: 'ClientSuccessWebUnitTests', 
      useBrowserName: false 
    },
    browsers: ['PhantomJS'],
    singleRun: false
  });
};

It can happen that VS Code debugger UI receives a 'stopped' event before the confirmation of a 'continue' request. It would be great if I first get the confirmation for the continue, and only then the new stopped one.

What is the best practice for replacing the builtin node-debug extension with this repo? Is it to simply delete/move the builtin one (on Mac: /Applications/Visual\ Studio\ Code.app/Contents/Resources/app/extensions/node-debug) and symlink this repo in ~/.vscode/extensions? Thanks!

From Dirk:

• clone: https://github.com/Microsoft/vscode-jshint.git
• change to vscode-jshint/jshint-server
• npm install
• npm run compile
• cd ../jshint
• npm install
• code .
• F5
• in the workspace create a .js file, close VSCode with that file open
• set a breakpoint on line 9 in extension.ts
• F5

Observe: breakpoint is not hit

The only workaround I found to make the debugger stop is to put a debugger; statement into the extension code.