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.
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.
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.
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.
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. ;)
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?
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.
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.
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.
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.
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.
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.
