Ask HN: How well does the Windows version of node.js work?
18 comments
I use Node on Windows regularly as I have a client whose stack is mostly based on .NET, but they recently started using Node as well.
I use Visual Studio Code. Atom also works well. I was told that Visual Studio should also work, but apparently I'm simply not clever enough to figure out how to make it do what I want it to do.
Path length is definitely an issue; I check out all git repos directly under C:\b\ which is usually enough to work around path length issues. Path separators usually just work as Windows is rather good at translating / to \, but still it's good practice to use path.join / path.resolve rather than "hardcoding" separators.
Getting node-gyp working is black magic and it requires the recital of arcane incantations, but it's doable. However, some node-gyp modules are not very well tested on Windows and fail all sorts of weird ways. For example (and this might have been fixed since then, haven't checked in a while) the "pg-native" module (native driver for PostgreSQL) builds on Windows, but crashes when you're trying to use it. Fortunately, many native modules have JavaScript-only alternatives that you can use on Windows.
Npm works well, but due to how file locking works on Windows (you can't delete (unlink) open files), you can't always run npm update while your application is running.
Generally speaking, once you have a solid initial setup, things tend to work well. I don't run Node on Windows in production, but it performs well for development purposes.
I use Visual Studio Code. Atom also works well. I was told that Visual Studio should also work, but apparently I'm simply not clever enough to figure out how to make it do what I want it to do.
Path length is definitely an issue; I check out all git repos directly under C:\b\ which is usually enough to work around path length issues. Path separators usually just work as Windows is rather good at translating / to \, but still it's good practice to use path.join / path.resolve rather than "hardcoding" separators.
Getting node-gyp working is black magic and it requires the recital of arcane incantations, but it's doable. However, some node-gyp modules are not very well tested on Windows and fail all sorts of weird ways. For example (and this might have been fixed since then, haven't checked in a while) the "pg-native" module (native driver for PostgreSQL) builds on Windows, but crashes when you're trying to use it. Fortunately, many native modules have JavaScript-only alternatives that you can use on Windows.
Npm works well, but due to how file locking works on Windows (you can't delete (unlink) open files), you can't always run npm update while your application is running.
Generally speaking, once you have a solid initial setup, things tend to work well. I don't run Node on Windows in production, but it performs well for development purposes.
Have you tried npm 3? Does its flattening solve your path length issues?
Yes, I use node 5 and npm 3 and it improves the situation. That being said, npm 3 won't help if the project's folder structure is itself deeply nested.
Visual Studio is an extra source of issue since it packages its own version of nodejs and with it npm. You can configure Visual Studio to use your global nodejs, however. I have mine setup this way, and Visual Studio uses my global nodejs 5 and npm 3.
Do you need Visual Studio for its C compiler? Or can you get by without it (eg, is there another compile you could use to build native stuff)?
As far as I am aware, on Windows, for C/C++ modules that need compiled, there are no options other than Visual Studio. I have to qualify this by saying that I have had an MSDN license for a decade and haven't been forced to find a work-around. If you could find a Community Edition of it that would probably be enough.
The other aspect of this question is how often this actually is needed. I'd say it really depends on the type of development you are doing. But you can expect that any project with a sufficiently large amount of dependencies will have at least one that requires building this way. But I am surprised how often this isn't the case, and often those modules are soft dependencies.
The other aspect of this question is how often this actually is needed. I'd say it really depends on the type of development you are doing. But you can expect that any project with a sufficiently large amount of dependencies will have at least one that requires building this way. But I am surprised how often this isn't the case, and often those modules are soft dependencies.
There are command line tools/minimal libraries that allow you to compile C/C++ provided in the depths of Microsoft's webs that can/will let you do this without a full on VS install. Typically good for setting up a build server/etc.
If I wasn't on a spotty network ATM I'd dig through my old blog posts to find where I wrote about it. In general though, if you can get a free version of one of the VS flavors, you'll save a lot of hassle just installing that.
If I wasn't on a spotty network ATM I'd dig through my old blog posts to find where I wrote about it. In general though, if you can get a free version of one of the VS flavors, you'll save a lot of hassle just installing that.
Based on Microsoft's node.js guidelines[0], it looks like you should be able to get by with just installing the Visual C++ Build tools and not the full VS community edition.
[0]: https://github.com/Microsoft/nodejs-guidelines/blob/master/w...
[0]: https://github.com/Microsoft/nodejs-guidelines/blob/master/w...
[deleted]
Ah, node-gyp. I completely forgot about all the f@$king problems that caused us.
> I check out all git repos directly under C:\b\ which is usually enough to work around path length issues.
Thanks. Could you use a Windows mount point for this?
Thanks. Could you use a Windows mount point for this?
Just wanted to add that at my workplace we regularly set up extra drive mounts just to get around the long path issue and it works fine. For instance we map G:\very\long\file\strucutre\ to X:
That's what we did and found it to work great for us. Occasionally we still had some that were just too long and had to hack about them.
My primary development box is on Windows (for reasons similar to yours) and Node.JS is for better or worse, my bread & butter.
The single biggest issue with Node.JS (or Python, Ruby, Lua, PHP, etc) development on windows is in my book the difficulty of setting up the build tools so that you can compile native modules. It always takes me at least an hour, as instructions seem to stop working between major OS versions, MSVC versions and the versions of whatever language you're using (relevant example: you recently had to patch psycopg2 to get it to build in the VC compiler required by Python 3.5)
Path-wise, you won't encounter any trouble: Windows accepts / just as well as the preferred \ and the OS supports long file names; it's just the tooling that's bugged. npm3 mostly solves the issue, but if you're stuck with v2, `npm install -g rimraf` to get a long-path-aware version of `rm -rf` that you can use to "reset" your node_modules folder.
The single biggest issue with Node.JS (or Python, Ruby, Lua, PHP, etc) development on windows is in my book the difficulty of setting up the build tools so that you can compile native modules. It always takes me at least an hour, as instructions seem to stop working between major OS versions, MSVC versions and the versions of whatever language you're using (relevant example: you recently had to patch psycopg2 to get it to build in the VC compiler required by Python 3.5)
Path-wise, you won't encounter any trouble: Windows accepts / just as well as the preferred \ and the OS supports long file names; it's just the tooling that's bugged. npm3 mostly solves the issue, but if you're stuck with v2, `npm install -g rimraf` to get a long-path-aware version of `rm -rf` that you can use to "reset" your node_modules folder.
There was an article (maybe came across HN) not that long ago that details the history of MS-DOS and Windows, and they made note of how originally MS-DOS was going to use \ as a file separator, and instead of C:\ it would've just been C\, but due to some deal with IBM (I think) they wound up switching their path conventions. Because all the old code supported the more conventional pathing it was essentially just left in, and over time it's meant that Windows generally handles \ and / pretty well at the OS level.
That's rather garbled by transmission. For the original, see https://news.ycombinator.com/item?id=11433139 . (-:
Thank you for ungarbling.
> Windows accepts / just as well as the preferred \
So someone can (naively) concatenate paths with / and fs.readFile() and require() etc will still work?
I'm on npm v3 right now anyway for the dedupe and better shrinkwrap features so no need for extra work.
So someone can (naively) concatenate paths with / and fs.readFile() and require() etc will still work?
I'm on npm v3 right now anyway for the dedupe and better shrinkwrap features so no need for extra work.
Typically the problems we've had with pathing on Windows is when the module we're trying to use doesn't handle Windows paths as inputs, the other way around hardly (if ever) caused us a problem.
I am pretty sure it even resolves something like /Program Files/My Program correctly to C:\Program Files\My Program. We just had a lot of modules barf when they got C:\Path\whatever and were trying to parse the path by hand or do other weird stuff like split on '/'.
I am pretty sure it even resolves something like /Program Files/My Program correctly to C:\Program Files\My Program. We just had a lot of modules barf when they got C:\Path\whatever and were trying to parse the path by hand or do other weird stuff like split on '/'.
B:\_purgatory>mkdir hello
B:\_purgatory>echo "test" > hello/world
B:\_purgatory>node
> var fs = require("fs")
undefined
> fs.readFileSync("hello/world")
<Buffer 22 74 65 73 74 22 20 0d 0a>
OK, I just have to ask... what are you developing that it deserves the project title of "_pergatory"?!?
B: is my workspace partition, and `purgatory` is just the name of a folder I use for files and folders that I will eventually either delete or include in an existing project (helps when I'm in over my head with git). Underscore is there to show up first in explorer
It's an interesting time to be asking the question, because the new "Ubuntu for Windows"[1] subsystem will provide another alternative for running node.js on Windows.
I certainly wouldn't want to try it now unless you really want to be a beta tester for Microsoft, but in a few months that may be the superior alternative for node.js on Windows.
1: https://blogs.windows.com/buildingapps/2016/03/30/run-bash-o...
I certainly wouldn't want to try it now unless you really want to be a beta tester for Microsoft, but in a few months that may be the superior alternative for node.js on Windows.
1: https://blogs.windows.com/buildingapps/2016/03/30/run-bash-o...
I did try it. Node works fine even though I didn't do anything exotic on it.
At my last company we built an internal build/deployment tool and dashboard. Because we serviced a lot of clients and a number of them were .NET projects, our tool had to be deployed to Windows. There were a couple of devs who did their work in Windows and I did mine in OS X, using a VM to test for compatability.
There was always something wrong, usually in some plugin that assumed weird things about file paths. I think we submitted like 25-30 PRs to various plugins, a number of which weren't taken in because they didn't want to maintain Windows compatability.
One of the bigger issues we had was in fronting the application with IIS and logging it. It's been about 18+ months now, so the specific are foggy but our application took a long time to be resilient on Windows, to the extent that we ran the same code deployed to Windows and Ubuntu for about 8 months and primarily everyone used the Ubuntu server because it was always working.
Windows is very often not even a tested platform for most plugins, which leads to very weird things very deep in code that take quite a while to figure out.
With all of that, the Node community moves fast, so you could hope life's better now than 18 months ago- but I doubt that the community suddenly decided to add Windows to their development cycle.
In the end, we wound up with a very stable, very awesome build and deployment platform that worked great for us- and unlike all the other options we looked at, handled the gamut of C#, Java, PHP, front end only, whatever projects we had and deployed them in all the ways they'd want to be deployed. 18 months on, with little maintenance the system is supposedly still going strong- so developing Node on Windows is possible and you can make it stable, but you will very likely be doing a lot of work on other people's projects that you want to use, and you'll need to be okay with that.
There was always something wrong, usually in some plugin that assumed weird things about file paths. I think we submitted like 25-30 PRs to various plugins, a number of which weren't taken in because they didn't want to maintain Windows compatability.
One of the bigger issues we had was in fronting the application with IIS and logging it. It's been about 18+ months now, so the specific are foggy but our application took a long time to be resilient on Windows, to the extent that we ran the same code deployed to Windows and Ubuntu for about 8 months and primarily everyone used the Ubuntu server because it was always working.
Windows is very often not even a tested platform for most plugins, which leads to very weird things very deep in code that take quite a while to figure out.
With all of that, the Node community moves fast, so you could hope life's better now than 18 months ago- but I doubt that the community suddenly decided to add Windows to their development cycle.
In the end, we wound up with a very stable, very awesome build and deployment platform that worked great for us- and unlike all the other options we looked at, handled the gamut of C#, Java, PHP, front end only, whatever projects we had and deployed them in all the ways they'd want to be deployed. 18 months on, with little maintenance the system is supposedly still going strong- so developing Node on Windows is possible and you can make it stable, but you will very likely be doing a lot of work on other people's projects that you want to use, and you'll need to be okay with that.
I use node on Windows everyday and very rarely run into any issues. Following the dev environment setup from microsoft's node.js guidelines[0] should take care of a majority of any issues you might run into with handling path length (tools for removing things > MAX_PATH), using c modules, etc...
[0]: https://github.com/Microsoft/nodejs-guidelines
[0]: https://github.com/Microsoft/nodejs-guidelines
I've worked with nodejs on Windows daily for years now and have very few issues. Almost all of those issues can be related to:
- Bad npm scripts in `package.json`; usually maintainers with a severe OS X slant who don't consider that setting environment variables requires some cross-platform love (getting better though thanks to an awareness of this in the community and packages handling it such as `cross-env` and `better-npm-run`)
- Modules that require being built via node-gyp require some combination of Python 2 and VS 2010. Once these are on your PATH there is no more friction.
- Path lengths are not an initial problem with npm 2 on install but will grow to be an annoyance later. The flat(-ter) module folders provided by npm 3 is welcome.
- Bad npm scripts in `package.json`; usually maintainers with a severe OS X slant who don't consider that setting environment variables requires some cross-platform love (getting better though thanks to an awareness of this in the community and packages handling it such as `cross-env` and `better-npm-run`)
- Modules that require being built via node-gyp require some combination of Python 2 and VS 2010. Once these are on your PATH there is no more friction.
- Path lengths are not an initial problem with npm 2 on install but will grow to be an annoyance later. The flat(-ter) module folders provided by npm 3 is welcome.
Yes, we develop many cryptocurrency/blockchain applications (e.g. Bitcoin, Ethereum) using Node.js under Windows. Some people use Visual Studio (I think the best) while others use WebStorm.
The issue with path length is almost always experienced with Visual Studio and when it is solved is because the developer moved the project to C:\ the same project works well with WebStorm.
I don't remember having issues with path separators, we even move the projects from Windows to Linux and they work without changes. There are typical recommendations when you use filesystem operations directly like using specific modules for handling paths.
Native modules are a difficult aspect of development, but this is not Node specific but general. We have similar experiences in other programming languages. We even wrote an article for a specific case http://blog.coinfabrik.com/installing-copay-in-microsoft-win...
So, we are happy developing in Windows and the native modules are the only critical aspect, but if it is just a compilation issue it can be solved with some effort.
The issue with path length is almost always experienced with Visual Studio and when it is solved is because the developer moved the project to C:\ the same project works well with WebStorm.
I don't remember having issues with path separators, we even move the projects from Windows to Linux and they work without changes. There are typical recommendations when you use filesystem operations directly like using specific modules for handling paths.
Native modules are a difficult aspect of development, but this is not Node specific but general. We have similar experiences in other programming languages. We even wrote an article for a specific case http://blog.coinfabrik.com/installing-copay-in-microsoft-win...
So, we are happy developing in Windows and the native modules are the only critical aspect, but if it is just a compilation issue it can be solved with some effort.
We develop in Windows and Mac and they have been remarkably solid with a few gotchas.
One, the case sensitivity of file names. Two, compiled modules have not behaved well on Windows in all cases. We tend to avoid them. Three, the path length has definitely caught us. However, NPM now mitigates that with a new flatter directory structure.
One, the case sensitivity of file names. Two, compiled modules have not behaved well on Windows in all cases. We tend to avoid them. Three, the path length has definitely caught us. However, NPM now mitigates that with a new flatter directory structure.
Which specific native modules have been a prob?
It makes me rip my hair out. I brought my own SSD to work to install Linux Mint because I was sick of Windows headaches. You are REQUIRED to install Visual Studio for most npm installs to work (for building stuff). Constant file path issues. That's corrected by deleting the node_modules folder which sometimes takes 20 minutes, and often also fails because the file path is too long which means you just have to rename it and have it forever stuck there unless you get some special software to remove it. Installing web stack takes longer on Windows and is error prone. Lots of smaller projects don't work well on Windows. You have to use inferior version of name version manager. The list goes on. Don't do it.
'npm install -g rimraf' will provide the special software needed to delete files whose path names are too long in Windows. I deal with this all the time with Atom extensions, and it drives me crazy. It drives me crazy that it's even possible for the normal file creation APIs to create files that the normal file rename and delete APIs can't process.
I was honestly in disbelief when I first came across it. It just seems insanely stupid on so many levels.
AFAIR, the case is that NTFS supports long file paths very well, and Windows has APIs to deal with long paths, but a lot of software (Windows Explorer inexplicably being one of them) uses old APIs that choke on paths over 260 chars.
`rimraf` solves the issue of deleting such files and it's one of the must-have tools when doing node dev on windows, like `grep` etc
`rimraf` solves the issue of deleting such files and it's one of the must-have tools when doing node dev on windows, like `grep` etc
I've been using Node on Windows for about a year and have had exactly zero of these problems. If Visual Studio has ever been installed, it's been done silently by npm (which I seriously doubt).
We're a .NET shop that has started using node for new projects, and it's been a happy path so far. Native modules have only rarely been an issue, only when they require a specific version of Visual Studio, of course different than the one we use. All our build tools are available under Windows.
Stability is not a problem either. Test and prod environments are linux boxes, but I have never seen a bug that appeared only on one OS, so cross-compatibility is not an issue.
And there are plenty of text editors and related software you might need to choose from, so I don't think you'll miss anything critical.
Been using node on win since 0.8, mostly for tooling (not prod servers). JS stuff works fine. I don't write C modules so can't tell. Bugs on Windows are rare, mostly smallish and easy to fix bugs on obscure one-man modules developed on osx - but once a module gets traction, it gets win support soon. No issues with paths, though I use node tools via git bash only.
The issues with paths generally manifest themselves in test suites due to sloppy test (expected /foo/bar, got \foo\bar) but in practice it doesn't matter. Use path.resolve in test, fixed.
The issues with paths generally manifest themselves in test suites due to sloppy test (expected /foo/bar, got \foo\bar) but in practice it doesn't matter. Use path.resolve in test, fixed.
As another node developer, I left Windows ~2y ago for Linux. node and it's ecosystem were already well supported on Windows back then.
Development-wise, I can't remember a single issue with node (file-watching even worked quite well). Working with Docker however wasn't nice. But I believe that changed in the meanwhile?
As a side-note: Ubuntu/Linux came a long way. I went back-and-forth between both a few times during the last ~10y. Things that scared me (window management being a big one) are a pleasure to work with in Ubuntu nowadays.
Development-wise, I can't remember a single issue with node (file-watching even worked quite well). Working with Docker however wasn't nice. But I believe that changed in the meanwhile?
As a side-note: Ubuntu/Linux came a long way. I went back-and-forth between both a few times during the last ~10y. Things that scared me (window management being a big one) are a pleasure to work with in Ubuntu nowadays.
Understood. I've used Linux desktops on and off since the 90s. Not discounting your experience, but my own is that every time I think everything is fixed, it isn't:
- My last Linux desktop was purchased for hardware that had 100% OSS drivers: even then compositing on an external display wouldn't work.
- The Windows machine I'm looking at has a version sold with Ubuntu. It's still pretty awful according to HN users.
I speak a lot, I need to be able to plug into every projector 100% of the time.
- My last Linux desktop was purchased for hardware that had 100% OSS drivers: even then compositing on an external display wouldn't work.
- The Windows machine I'm looking at has a version sold with Ubuntu. It's still pretty awful according to HN users.
I speak a lot, I need to be able to plug into every projector 100% of the time.
File watching is a pain in folders where you have more than a few files. With nested folders and hundreds of files, it takes usually 10-15 seconds to initialize the file watcher. Then it works fine.
If you wait for a couple of months for Ubuntu for Windows to be bundled in the new release of windows you can just use that and probably avoid most of the issues mentioned here.
Works pretty well. There are some npm packages that don't work with windows. [subst]( https://www.microsoft.com/resources/documentation/windows/xp...) solves the path issue. Also with bash on windows in the future it shouldn't be any issue.
So the thing is, if you're doing Node development on Windows, you're not going to be running in production on a Windows box, right? So use Vagrant or Docker or some other "run in a virtual Linux environment" thing, which will make your dev machine match your server environment more closely.
I hear MS is really pushing Node on Azure. There was another HN article recently mentioning something like $100K of discounts for the first year, but to tell you the truth, that wasn't really enough to pique my interest in Azure. The only reason I'm here is for disaster stories and popcorn ;)
Things must have gone pretty bad if Azure is offering Linux now.
Things must have gone pretty bad if Azure is offering Linux now.
I have been developing side-projects with node on windows for years and I've, other than some "native" modules not building, didn't have any big problems. Everything's been very stable for me. For the native modules, it's usually resolved if you have MinGW or something similar.
You could still use Docker or a vagrantbox if you ever encounter problems.
I use OSX at work and GNU/Linux and Windows at home. The only issue I've had are native modules but with msys2 I've usually been able to solve them 90% of the time.
For various reasons - mainly around hardware - I'm interested in Windows. I use Sublime, Sourcetree, git, RethinkDB, and other apps that have Windows 10 versions. I also use Sketch which has no Windows 10 version, but Adobe XD is similar.
Does anyone develop on node / Windows every day? How well does it work? Do you have issues with path length? Apps assuming path separators? Do you have issues with c modules? Do you lose productivity from random brokenness? Or is it pretty solid?