This project is read-only.

A whole bunch of bug fixes on their way...

Jun 27, 2014 at 9:34 PM
hi everyone,

just wanted to give an update that the team is about to release PTVS Beta 2 next week, which means we're finally coming up for air and spending more cycles on fixing NTVS issues. in the next couple of weeks you should see lots of bugs filed and fixed & pushed to codeplex. we'll roll all the fixes into a Beta 2 release as soon it reaches stability. specifically many of the formatting, memory, stability issues are addressed. if you have any issues not already captured on CP, please file them as soon as possible...

thank you again for being patient!

N/PTVS team
Jun 29, 2014 at 12:37 PM
Really looking forward to the release.

At the moment there are a couple of NTVS projects that have problems when it comes to editing and saving code files - the IDE hangs for around 8-10 seconds on every save operation for a file, and TypeScript intellisense in quite sluggish.

The TypeScript intellisense problem also occurs in non-NTVS projects. I've posted the issue on the TypeScript forum.

However, I'm wondering how much of a role the NTVS plugin plays in all this.

In any case, thanks for the update.
Jun 30, 2014 at 7:10 AM
thanks nabog.

do you have filed for these issues?

would you interested in taking an early build for a spin?

Jun 30, 2014 at 10:16 AM
@Ptools, I've not filed this particular issue because I have not been able to reproduce it, and also I'm not able to share my solution.

I'm definitely happy to try an early build. Let me know what I need to do.
Jul 2, 2014 at 12:21 AM
nabog, we should have a build late this or early next week as a candidate. will ping you if you have 'allow contact' set in CP.

Jul 3, 2014 at 2:54 PM
Thanks for the update, I'm really looking forward to the new release. Early visibility of a early build would be great.
Jul 3, 2014 at 3:26 PM
You have built a great framework for testing server-side TypeScript (or JavaScript) code.

I sincerely hope work item "Debug selected tests does not stop at breakpoints" gets fixed, because it's rather painful not being able to debug tests. One is forced to rely on adding console.log at various points in order to determine why a particular test is failing.
Jul 4, 2014 at 12:46 AM
alright folks - the devbuild is available at:

please give it a spin -- thanks!

nabog - we'll look at it, but it's on in this build, sorry...
Jul 10, 2014 at 6:22 PM
Not able to try out the 3-July dev build because the test cases are not getting picked up.

There is also an unreproducible bug in the 14-May release that is causing certain tests to not get picked up. This seems to have something to do with importing a type into a file:
  import foo = require('path/bar');
It would really help if someone put together some documentation on how the test discovery works - in particular for tests defined in TypeScript files.
Jul 11, 2014 at 12:57 AM
@nabog, can you check that the test case is using ExportRunner. Previously the framework was called Default. If your project is older and has tests marked to use the Default framework you'll need to update them to use ExportRunner. To do this, change the value in the properties dropdown to ExportRunner for each unittest.js or unittest.ts file. Alternatively if you have lots of files you can do a find and replace in the njsproj file.
Jul 11, 2014 at 9:54 AM
@RickWinter, I had changed the "Test Framework" property for a few files to "ExportRunner" and only one of those changed was working. But today when I did a find and replace in the .njsproj as suggested all the tests were discovered. So thanks!

The other problem of tests dropping out in the presence of require calls is unfortunately still there.

I tried isolating the problem, but when I moved the problem files to a new project they just started working again. All our Node tests are defined in a single .njsproj, so the problem is somehow related to the tests in adjacent files.

If there is some documentation on how the system identifies test cases defined in a particular TypeScript file then that would help me to reproduce the issue.

Jul 15, 2014 at 6:55 PM
TypeScript is treated almost identical to JavaScript. The only difference is that at discovery time we switch from the .ts file to the underlying .js file.

At the moment the best documentation is the testframework source code. We'll have better docs by the time we release. For now I can walk you through and answer questions as you have specific ones.
The test discovery is kicked off when a test file changes, is added, or a build event is fired. At that point VS will call us back telling us to report the list of valid test containers. NTVS then goes through the project and identifies which files are test files. We treat each file as a container. Its at this point that we do the trick to switch from the typescript file to the underlying javascript file. We pass that list back to VS and VS subsequently fires an event telling us to discover tests. For each of these files we invoke the "find_tests.js" script which in turn calls into the appropriate TestFramework "find_tests()" function. That will discover each test and send each test back to VS to display in the Test Explorer window.

The TestFrameworks, which by the way you can add your own, are found in our Extension folder
<program files>\Microsoft Visual Studio <vs version>\Common7\IDE\Extensions\Microsoft\Node.js Tools for Visual Studio\1.0\TestFrameworks
If you wanted to add your own framework you simply do two things.
  • Create a new folder under TestFrameworks. The folder name will become the TestFramework name in VS.
  • Add a new .js file with the same name as the folder. This js file needs two exports, find_tests and run_tests.
In your case you are using ExportRunner and can find the discovery logic in exportrunner.js.
Marked as answer by RickWinter on 8/12/2014 at 10:32 AM
Jul 18, 2014 at 12:39 PM

Many thanks for putting that together. It was quite useful.

I've managed to track down the problem - it was due to a TypeScript bug, but it would also help if errors in the test file are propagated to the console.

I've opened work items for both.

No error for invalid relative path in require(...)
Errors in test file should be printed to the "Test" output