Wow this looks pretty amazing!

How do you handle the super-long paths npm is so fond of? On Windows I often run into issues when searching or trying to manipulate a solution containing anything npm due to too-long paths.

We try to mitigate the issue in a few ways:

1) warnings when you hit max_path that offer to run 'npm dedupe'

2) sometimes that doesn't work, so we also suggest people start their projects in a short path like c:\src (embarassing, I know)

3) patiently await a flat node_modules directory - http://blog.npmjs.org/post/111968476155/npm-weekly-6

4) groan very loudly when it happens - no good keeping those emotions bottled up ;-)

luckily #1/#2 cover most cases

If you use git, open a git bash window and do it from there. If you don't use git, install cygwin and do it from a cygwin bash window. Both are *nix-simulated shells and are not subject to the MAX_PATH limit. I do most of my command line work using Power Shell, but I always have a git bash terminal ready for npm, jspm and other similar path-length-affected tools.

I have run into this problem as well. Manually modifying packages is not fun.

See my comment above, but if you do this frequently... we have a feature that enables you to right click on an installed npm package in the npm tree in Solution Explorer and open the relevant folder in explorer

I use a tool called flatten-packages [1] and I usually do all of my npm work while visual studio is closed (and use short root paths as mousetraps suggested). I just flatten them after adding/updating/syncing packages.

[1] https://www.npmjs.com/package/flatten-packages

That's worked well for me, too. The biggest problem with long file paths is the deeply nested dependencies, so flatten-packages handles it for me.

Any chance that it'll support Babel (known previously as 6to5) + JSX (The react extensions to JavaScript)? I love Visual Studio and I also love to write ES6 - I don't want to choose.

make a feature request! we're a small team, so we have to prioritize - generally the policy is to build what people want. works well enough :)

https://nodejstools.codeplex.com/workitem/list/basic

I added one for JSX: https://nodejstools.codeplex.com/workitem/1916

JSX sounds great. I hope more people vote for it.

Ooh, tracepoints, DO WANT! Are they only available in one of the paid versions of Visual Studio?

The VS debugger is excellent, its probably the dev tool I miss the most since leaving C++ and going to JS, and tracepoints are the feature I wish for most frequently in a browser debugger.

So I was about to naively suggest the VS team could push for tracepoints in IE, but OMG! Tracepoints are in IE11. Where have I been? In prejudice-land. This might mean I have to open my mind and use IE for dev, though the bias runs wide, I still might have to use it in secret for a little while, at least at work. ;)

We've got breakpoints, conditional breakpoints, tracepoints... All the points, really ;-)

I don't think you need one of the paid versions, but I'll double check and edit this if I'm wrong.

Is there a simple way to use VS without the Solution files? Templates and Solutions are fine for creating a entirely new project, but if I have to work on someone's else code I'd prefer to have a basic "File Explorer" over Solution Explorer / Team Explorer. My attempts to create a new Solution file for an existing code ended with a new directory (or a couple of them) with a boilerplate code... Am I missing something obvious here?

Also, I've noticed that if I open a few files the IDE creates "Virtual Solution", but it's hard to tell which files are there, and which don't. For example: TypeScript files are, but no such luck with SASS.

P.S. And a CMD/Terminal in a panel (akin to the Output panel, but with an... well, input) - is that possible?

Hi bgarbiak,

You can use the "From Existing Node.js Code" project template to create a project from a folder, but the project file itself is a requirement for visual studio and also allows us to include helpful metadata (whether or not to analyze a directory, etc - most IDEs/text editors include a project file for this very purpose - they just hide it a little better). That said, at some point we'd like to change things up so that the project does feel more similar to the folder/file experience you might expect.

This is to change the project file to be more "transparent". https://nodejstools.codeplex.com/workitem/1855

There's also another issue to directly open a folder without requiring the user to take steps to create the solution/project. https://nodejstools.codeplex.com/workitem/209

Additionally, like rlp mentioned - make sure that "show all files" is turned on so that you can see everything in the folder, not just files you've defined as being a part of your project.

Hope that helps - let me know if you have any other questions.

Try clicking the Show All Files button at the top of the solution explorer. It will show everything by folder, which I think is what you're looking for.

Great work, looks very nice. Will give it a whirl when I get home.

In the meanwhile, I noticed that you support intellisense. What are the limitations to this? What patterns will get correctly picked up? I assume prototypal inheritance will work fine (of course), but will any of the BaseClass.extend()-style inheritance mechanisms that some frameworks seem to favour (e.g. Backbone) work?

While we're at it, is the static analysis tools you built for this public? I'd love to have a look at them.

> While we're at it, is the static analysis tools you built for this public?

maybe this?

http://nodejstools.codeplex.com/SourceControl/latest#Nodejs/...

Looks like it, yeah. Thanks!

Let us know if you have any questions! There's some _really cool_ stuff going on there, but it can be tough to wade through depending on your experience.

Any plans to make deployment of io.js easier to Azure websites?

Also - any way we might get "break on exception" like with C#?

Also - any plans to support debugging promises better?

Break on exception? Done! http://nodejstools.codeplex.com/wikipage?title=Debugging#bre...

We have SO MANY PLANS, so please upvote or request the ones you think are important :) https://nodejstools.codeplex.com/workitem/list/basic

I'd vote for the "Move to github", but (fittingly enough) I'm not going to create a codeplex account just for that purpose. :-\

Haha, fair enough. Then I suggest you follow @NT4VS on Twitter. We'll let you know when it happens. :-)

Also re: io.js + Azure websites - looks like someone wrote a script to make it easier!

http://azure.microsoft.com/en-us/documentation/articles/web-...

Is this going to make it easier to deploy NodeJs apps to Azure then?

Love Azure, but had a hard time getting my NodeJS stuff up to Azure without some major issues.

If you haven't already been in touch with someone to get this sorted out, can you e-mail me (jon.galloway at microsoft dot com)? Would like to make sure we're tracking and fixing any issues you ran into.

Same, and I gave up trying to get Node to work with SQL Server. Ended up at Heroku because of this.

The node MS SQL bindings are still terrible, so I haven't really bothered much with Node because of it

I'd recommend using Edge.js for that:

http://tomasz.janczuk.org/2013/06/access-sql-azure-from-node...

http://tjanczuk.github.io/edge/

http://tech.pro/tutorial/1852/how-to-leverage-sql-server-wit...

I gave up on deploying my node.js app to Azure after finding that several modules I was using were simply not possible to run on Windows. Wasn't worth the trouble to refactor and avoid these dependencies.

Windows is not a priority for most node.js devs, so unless you're doing something pretty simple/mainstream, you're likely to run into trouble.

Azure supports OSes other than Windows.

Yes, it does. But if I'm just going to spin up a Linux VM on Azure to host my node.js app, there's not much reason to use Azure over other cheaper options. So that's what I'm doing.

This is a trend amongst developers who rely on monolithic programs for development.

YOu should really just stop developing on windows and learn to embrace docker.

Very nice work, I'll test it on my workflow by the next hours :)

Awesome! Please, please, please let us know if you have any feedback!