This is great news, but aren't there bigger fish to fry with really supporting node.js & npm on Windows? The 255 character path limit bug has been around for a long time and still unresolved/broken on Windows (see https://github.com/joyent/node/issues/6960 and https://github.com/npm/npm/issues/5641). Suggestions to fix it on the Windows side have been closed too: http://visualstudio.uservoice.com/forums/121579-visual-studi... Would be nice for people to stop throwing it around like a hot potato and fix it for good. Although it sounds like an edge case, it's actually really common for some libraries to his this limit and be unusable on Windows.
Thanks to Microsoft's fanatical dedication to compatibility I don't see how it will ever get fixed. I think they could take a lesson from Apple here and have DLLS/EXEs contain SDK versions against which they are built, then mandate that Windows 10 apps must support a larger MAX_PATH. Of course if they were into learning lessons, they'd have done fat binaries so a single install could easily support 64-bit and 32-bit (or a single DLL could contain 64-bit and 32-bit versions).
For those not in the know, MAX_PATH and PATH_MAX (ugh) are defined in the Windows headers as 255. Because it was public people copied that constant and spread it around. So many apps and libraries out there are hard-coded to expect 255 that even if you change it in the Windows headers a million things will still be broken.
Even if you overcame that limitation, you'd have a situation where paths no longer worked reliably if they got passed around (or worse, long paths would trigger buffer overflows in poorly written apps and drivers).
You could fix it by passing apps not declared as large-path aware a shortened virtual path but the testing/edge case burden would be enormous.
So this is an example of a really quick decision one programmer probably made by themselves many years ago that we are forced to live with because the pain of changing it is too great compared to the benefit we'd receive.
MAX_PATH is a #define, so it just gets literally substituted when compiling, there is no need for people copying it. After compilation it effectively is a hard-coded constant, indistinguishable from literally writing 260 (it's not 255).
Since the problem seems to be mostly with cmd.exe (and tools that use it), could not Microsoft ship a cmd.exe (with a modified name, so it does not break old stuff) that handles long path name by using the unicode API ?
EDIT:
Re: fish: Indeed - we have some big fish to fry, but luckily msft is a big company that can fry multiple fish at a time. Personally, I'm excited to help improve the Node tooling story by frying this fish, and passing our learnings and feedback onto the the other teams @ msft so that they can improve their recipes. Ultimately, we strive to have a complementary set of fried fish. And maybe some vegetables too... :)
Node uses the Unicode functions so no need, but lots of tools in windows break (cmd.exe notably) so things like child processes don't work on long filepaths. You can actually watch `npm` write to files past the limit by using the Unicode functions, but trying to access them via child processes generally fails (and things like IDEs can't see them). The other problem is that using the longer paths turns of filepath expansion.
I posted this in the comments in the blog as well:
With regards to the technicalities of max_path itself... the issue is with the .NET file I/O API, which doesn't allow you to use \\?\ paths to work around it, and is too big for our team in particular to do much about. Here's a good article that might provide a little more context (it's a little old, and these "plans" they speak of never actually materialized.)
> The 255 character path limit bug has been around for a long time and still unresolved/broken on Windows
I don't know, I was cussing out both node.js and Windows. "Let's put all the dependencies in subtree even if they repeat 20 times throughout or paths start wrapping around 3 times at the terminal".
This! This really needs to be fixed! My first experience of getting a node application running on Windows ran into this very quickly due to the crazy dependency tree npm creates. While npm could certainly be improved this limit is so old it really needs to be fixed.
Once again, these limitations are not with Windows itself (see all the C++ Unicode file functions / file longpaths). In general Node supports long paths just fine (you can watch `npm` write past the 260 [wtf?] char limit). The limitation is in other programs trying to respect MAXPATH even when they should be moving to Unicode functions for compatibility reasons / lack of knowledge. It should be noted that compatibility breaks not just from long paths causing errors, but automatic file expansion does not occur on long paths. So we get into even more special snowflake situations where sometimes files with expansions work with older functions but not with newer ones.
But the fact that Unicode functions don't expand adds an interesting problem for us; the MAXPATH respecting (and outdated) _A filesystem functions can cause a collision for non-expanded paths we get to fun things where you can have different FILE objects if you use old _A functions vs _W functions. The inverse is also true where you can collide by moving from _W to _A.
So! If we do start using old _A functions we actually can cause problems by directing to new files that would cause expansion because of file expansion being turned on.
Behind the times on web dev for so long, now busting out open source left and right, teaming up on Angular with Google, jumping on with nodejs, modernizing their tools, "gently" pushing locked in MS web devs out of the darkness of that Web Forms madness into the light of real web development.
I've always been a LAMP stack dev but they have at least caught my attention as of late.
> Gotta hand it to Microsoft. Behind the times on web dev for so long, now busting out open source left and right, ....
Open Source is not just about opening up some source code, it is also about how you act in the larger interests of the community. Just earlier this month, Microsoft sued Kyocera over patents on Android. Microsoft has sued every Android phone maker so far, and have forced some of them to make Windows phones. Their position on Linux infringing unspecified patents has not changed or been clarified.
Microsoft is playing the Open Source game because they really have no choice. Open Source has thrived and will thrive without them. Microsoft doesn't deserve our attention until they stop abusing patents.
Forest, meet trees. MS is a very large company with divergent groups given KPI's that turn into seemingly contradictory actions.
It's the Kabuki theater of patent suing in order to eventually end up at a table finding a way to forge ahead "together." It's something the large IP players have all been doing on the long tail of the IP consolidation wars.
IP royalty harvesting is separate enough from the open source efforts that it's picking nits a bit.
MS is growing open source because players and groups have beaten the drum to get there and the lumbering giant has shifted. The seeds planted years ago are bearing fruit.
You can sing the war song, but Open has won. Glory be! Nobody is looking for everyone to jump into Azure as if it were the latest awesome distro because a bunch of core dev tools, frameworks, and open-friendly advances have happened, but on the current trajectory, we will see the old walls of our discontent torn down by those who built them.
You get enough .net devs to come out of their caves and you could be wading through as many "MS + my favorite open source project" posts as not... and the communities, overlapping into harmony, will have bigger upsides for both than downsides.
It's becoming an increasingly good time to be a developer. When those you hate become undifferentiated from yourself, do you grow to hate yourself or to love the one you hated?
>"gently" pushing locked in MS web devs out of the darkness of that Web Forms madness
Minor nitpick on your otherwise positive comment, we have been using ASP.NET MVC for almost ten years now (ok eight). Webforms have long been a thing of the past, at least in the circles most devs I know move in.
From my admittedly limited perspective, it just NOW seems that Microsoft is really pushing for devs to meet up with real web development.
I can't tell you how many conversations I've had with MS devs who only know how to develop with web forms. They've never heard of grunt, node, MVC (the concept in general, let alone the option in .NET), SASS, NoSQL, RWD and the list goes on and on. It's like they've been living in a closet.
Not that they have to use ANY of those I listed -- but to KNOW such things exist!
For so long it seemed MS's mantra was "keep using only our stuff, its okay, don't look out the window at everything else going on". And so many that I've met just said "okay".
Now I feel there is a concerted effort from them to reverse that and really push education beyond the MS closet; it is very interesting to watch devs come out into the sun, blinking.
Again, just amongst the MS devs I've had the pleasure of working around, talking to online and off, at meetups and at jobs. But yes, only from my limited circle. Never meant to imply anything other than: I'm excited for MS devs and myself, as I'm actually wanting to dip my toe in the water as well and pick up .NET.
I work on a 12 year old application that's still current, and we're just now making the transition from web forms to MVC in that application. It's so nice that MSFT has a big eye toward backwards compatibility, allowing web forms and MVC in the same project.
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.
I was really excited about Visual Studio for a chance at Coffeescript intellisense, however I learned after the several gig download it wasn't supported. It seems there is basically no way to get proper autocomplete in any editor for CS, suggesting maybe I should just consider Babel for ES6/7 despite my massive love for CS and giant projects built in it.
Have you tried the (free) Web Essentials extension? It adds CoffeeScript support to Visual Studio, as well as a lot of other useful webdev features. http://vswebessentials.com/features/coffeescript
You might want to check out sublime with the 'Better Coffeescript' and 'CoffeeComplete Plus' packages. I've been using it for a while and, while it's not perfect, it's the best I've found.
I agree, and it's close to usable but not quite. There are a few outstanding breaking issues on the repo that I wish someone who knew how it worked could fix, but the project looks abandoned.
I actually heavily modified sublime-better-coffeescript to support highlighting function-calls and I added proper CSJX support.
Been meaning to make a pull request; but these Sublime plugins are always so easily abandoned and under maintained that there's no point.
I've tried Webstorm and assumed IntelliJ IDEA had the same pitfalls, which, if I recall correctly, was poor performance and flaky autocompletion. I'll have to download it anyway and try though, if only to see what it looks like to have intellisense!
I remember a bunch of problems have been discussed earlier [1] concerning node.js on Windows, such as file-system path length limits and broken symlinks and lack of modules actually tested on Windows.
That was almost a year ago, so how do the things stand now?
windows not being a priority won't change, because windows as a deployment target is pretty much a joke.
I mean... desktop environment on your application server ... lol?
There's so much friction legality and culture wise to getting a windows server to spin up, get developers to use good practices, encourage automation and resusability...
> windows not being a priority won't change, because windows as a deployment target is pretty much a joke.
I take it you haven't done .Net development? It's incredibly easy though Docker and similar tech wasn't developed for Windows so some of that has lagged behind.
> I mean... desktop environment on your application server ... lol?
This is a pretty old way of thinking; it's simply another way of managing your application server. This really isn't a big deal anymore.
It does mean something, that Node.js has a backwards version numbering scheme. That's one of the first things the io.js people corrected in their fork (they are strict semver and started at 1.0.0).
Honestly, it's good to see a lot of .Net developers getting to see some sunlight. A lot of really interesting things have happened in JavaScript land over the past few years, and there are a ton of really good programmers who have been in .Netland for far too long.
If they free up the developer license, MS will get lots of Apps in for their phone versions as well..They are already supporting javascript for native apps..
How many people do you think will actually use this?
I just really cannot ever see mass use of azure and visual studio in the web ecosystem. The people writing nodejs code are all using vim and unix, and you're asking them to give up their workflow and change operating systems. I want to be able to poke around in bash. (edited back in)
Sure, some people new to web programming might go this route. But the next big web framework certainly will be on unix first. MS is now in this perpetual state of trying to keep up, and I just can't imagine why anyone serious about web programming wouldn't be on *nix.
Based on a totally-not-statistically-significant-survey our team conducted, we are seeing that yes - many node devs are deploying to Linux, but developing on Windows. We support this scenario through remote debugging to any OS. Azure not required :)
We also try very hard to make sure that NTVS works well with people's existing tools and packages - so if you run into an issue, please let us know (or better yet, make a PR!)
You're only seeing part of the picture. There are a lot of Windows shops out there globally -- not just enterprise-oriented .Net consultants, but all kinds of companies from small web agencies to specialized software vendors.
I've worked with some of these people on the web agency end of the spectrum. They're good at what they do, but they're absolutely not interested or specialized in anything sysadmin-related. For them, Unix is a hairy old beast and Microsoft is the company whose solutions are imperfect but accessible, and that has allowed them to concentrate on their job for the past 20 years.
As Microsoft adds new technologies to their palette, these users will pick it up. They'd never do it on their own as long as it involves steps like "just spin up a virtual Linux box on AWS"...
On HN, it's easy to start assuming that everyone speaks Bash as a second language, but that's very far from the truth.
The people writing nodejs code are all using vim and unix
No they aren't, that's just your perception because you are surrounded by those that are.
AFAIK Windows Node developers are still a minority, but that doesn't mean they're not a sizable group of people. A lot of code is written in corporate environments in C# and Visual Studio - adding Node to that mix is a sensible bet on Microsoft's part.
Completely agree with you , But even all node.js dev's are user of unix/vim/emacs (I am emacs user though) this does not mean Microsoft should not develop tools for its users.Microsoft try to attract developer to its own platform , which is OK , at least I think it is ok. Every Company doing same thing.
The same reason I use *nix on the desktop: I like to be able to poke around on everything.
It's really scary for someone new, but power users like environments where everything is modifiable and hate GUIs.
I like being able to configure nginx a certain way. I like being able to get into a psql shell and play around with my data. I don't want to just give someone a git repository and magically press some buttons in their UI and have it work, because when you inevitably realize you want to do something special, you're stuck.
Not to be at all rude or confrontational, but I think there's a lot of folks in the open-source communities that have no idea how drastically their numbers are DWARFED by the number of devs working in enterprise computing. And those enterprise devs often have no use at all for "poking around", for better or worse: their priorities are other, entirely.
Different strokes for different folks, but there's a lot more folks stroking the corporate way.
MS has been pushing more and more for all of their tools to be scriptable through powershell, to give you just that. Getting stuck is harder and harder these days. Hell, powershell has features I'd love unix shells to copy, like being able to import libraries and use their classes and functions like any other shell command.
Yeah I was being hyperbolic, but my point still stands. The LARGE majority of developers have accepted unix as their overlord, and that poses a huge problem to microsoft as they're a second thought. They're forced to try to fit new frameworks into their ecosystem, rather than on unix where developers expect it to run.
I see it ultimately as damage control. With the overwhelming majority of developers on unix, you're not going to see microsoft hang out in the server market for very long. I think they'll hang onto the office crowd, but nothing on the backend.
This, of course, is just the opinion of a 20 year old unix nerd, who became one because his father is a microsoft fanboy. I rebelled in my teenage years by infuriating my father and installing linux. I still think I raise some valid points.
What evidence do you have that the majority of developers are on Unix? Just web devs or all devs?
I doubt that it's true in either case. IT departments around the world employ programmers to make all sorts of business apps including internet/intranet web apps. Even some very small companies have custom apps to do business and the vast majority of businesses are using Windows.
And this is a great development - it means for future enterprise projects, Node will become a more realistic choice, because it means that using Node on a project doesn't require orgs to build entirely new infrastructure to support * nix deployments or dev environments.
For the most part, npm packages work fine on both Windows and nix platforms. However, it is pretty clear that most are developed on, and have fewest problems with, nix. I believe that is due to the massive popularity of Macs with the JavaScript-focused web dev crowd.
Indeed. Somewhat related, I read about this big car manufacturer that's started building cars with the steering wheel on the left side.
Silly, right?
I mean, who would want to sit on the left side of the car when they're driving? Nobody I know ever has. I mean yeah, you see them on the road every once in a while, but it must just be people new to driving who haven't learned better.
Everybody drives on the left side of the road (at least everywhere I'm aware of), so it just naturally follows that you need to have the wheel on the right. Switching things up would force everybody to completely change up their driving workflow.
Lots of .Net companies dabble in Node.js and other alternatives to .Net and any competent developer is capable of creating sites on any operating system with a little bit of time and patience to learn.
I've been doing .Net development for over 5 years and my newest site is based in Node.js hosted on AWS. I am currently using Web Storm, which is great, but this plugin is definitely something I'll check out and is probably created for people like me: Someone who is a .Net developer, already has VS, but has a need for Node.js code.
I think your original comment mentioned that you'd want console access. While I was grabbing a screenshot, it looks like you edited your comment and removed that, but I think that was a valid concern.
Wow, that's fantastic. One of the things I love about Google's cloud is the easy SSH-in-browser. If Azure has this I'd love to use it. I hope it's just not tied to that terrible new portal. It's just so slow (in rendering, esp. over RDP) and clunky and laggy and confusing. The old one is far better (and would be all I want if they'd just move all the services I never use to the bottom so I don't have to scroll).
Jon, this is something which should really be better promoted. I follow most of the interesting .net peeps on twitter & have listened to Scott H's pod + Herding Code for years.
This is the first time I've seen this, which is a shame, because it solves a lot of my misgivings with Azure..
node.js has been used heavily inside Microsoft for quite some time so even if they created this for internal use only it wouldn't be a waste of time. Microsoft employee here.
And I think you vastly underestimate how popular Visual Studio is among enterprise developers - they're doing web development as well.
I don't have access to anyone inside of Microsoft, So I bring this up here, please tell Microsoft to develop official ssh client (With server it would be even better, but for now client I think would be enough) , I am tired of using putty for SSH'ing into my virtual machine. (or at least they can fork putty and make it official).Even in git plugin in visual studio they developed there is no SSH support.
Thank you , last question , are they reliable ? ( I am installing them right now , but I think as you mention them , you can answer this question better ) Because I use SSH in my work and research all the time , I am kind of tired of putty and its bug's.
Check out MobaXterm [0], there's a free version but I ponied up for the Pro edition after just a week. I use it daily and its X support is really bloody good. I run PyCharm (and other stuff) on a CentOS machine but the GUI is on my Windows desktop.
It's super cool for people wanting to do node on Windows. I used the beta while doing a small side project at my last job, and they worked well for that project.
My issue isn't necessarily azure and VS. It's the state of node on Windows. It's a second class citizen compared to the versions for posix compliant OSes. There are things that just don't work on Windows without installing VS, which is undesirable for deployment, and that's assuming they work even after VS is installed.
I'd rather spin up a local Ubuntu VM and write code in WebStorm, and that's what I do. I get debugger support, test runners, code completion, etc. Plus, I can then just deploy to cheaper VPS providers (DigitalOcean, Vultr, etc).
Fwiw we have remote debugging to any OS, so you can remote debug your app regardless of whether or not it's running on azure. We are striving to streamline this experience as much as possible, so any feedback or ideas you have on how to mitigate some of windows issues you've run into would be super helpful. :-)
The two major issues I have run into with doing node on Windows are likely out of your control. First is the file path length limitation, which conflicts with the nesting of npm dependencies. Second is dealing with any packages that depend on node-gyp for compilation. It shouldn't require an entire IDE to be installed in production just to build your dependencies that need node-gyp compilation. Not to mention that the process is problematic even in dev if you're not lucky enough to have installed the exact expected dependencies. I found it easier (and more portable) to just use a VM running some *nix flavor (Ubuntu for me) and deploy to a similar environment.
From my personal experience, if I'm not on Windows I use PyCharm for my IDE, but when I am, and I have VS installed, Python Tools for Visual Studio is really what I consider, Microsoft's hidden secret for VS. It really is a powerful tool, it would not surprise me if NTVS is right up in the same level of quality. Really great tools. Otherwise I try to go for JetBrains.
I do not know what you are talking about but the majority of companies that I have been working in the last decade use Microsoft Windows as operating system. They have absolutely no way they want to support *nix and Windows, so the development is done on Microsoft ecosystem. The next big web framework... again you look to be really close minded in your reality. All the new stuff is cross platform... even the next Asp.Net framework can run on every system. Stop the Microsoft hates and start opening your eyes...
Ultimately, MS' business in web development is tied to selling an IDE and Azure. Both have had to change to incorporate the tools people are using (JavaScript), not just the tools MS control (C#/.NET). I agree, the "Embrace, extend and extinguish" philosophy has apparently been replaced with "Embrace and hope to stay relevant".
I think they are doing a good job at handling that change. I don't personally want to be constrained to doing everything within an IDE, and I'd rather use the tools directly than have them abstracted to look like native MS tools, but that's their business model, and it is slick and works for a lot of people.
I can't speak for other teams, but re: NTVS... we definitely dont want to force abstractions upon you. For instance, with the npm integration, we provide UI where it makes sense (exploring/managing your packages, searching for packages), but you can drop into the cmd line or .npm command in the interactive window anytime you please. Think of it as semantic zoom - allowing you the flexibility to traverse the levels of abstraction when it makes sense. Are we 100% there yet? No. But I consider that to be the ideal experience, and we're definitely trending closer to that vision.
Thoughts? I'm especially curious to hear how you think we can improve the existing experience so that it caters better to your workflow. What are some of the abstractions that get in your way?
Bascially most .NET developers and other developers using Windows likes this. Why complain that a tool exist on a platform you don't use?
Please ask MS for a Linux version of Visual Studio if you want to and think that would help Linux users.
