
Ask HN: How well does the Windows version of node.js work? - nailer
I&#x27;m a node developer, I&#x27;ve been developing on Linux and then OS X for the last decade or so (in Python before node came along).<p>For various reasons - mainly around hardware - I&#x27;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.<p>Does anyone develop on node &#x2F; 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?
======
DrJokepu
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.

~~~
bryanlarsen
Have you tried npm 3? Does its flattening solve your path length issues?

~~~
DrJokepu
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.

------
za_creature
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.

~~~
nailer
> 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.

~~~
za_creature

      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>
    

As for require, iirc "/" is part of the spec and gets normalized to the OS
standards afterwards

~~~
chris_wot
OK, I just have to ask... what are you developing that it deserves the project
title of "_pergatory"?!?

~~~
za_creature
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

------
bryanlarsen
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...](https://blogs.windows.com/buildingapps/2016/03/30/run-bash-on-
ubuntu-on-windows/)

~~~
kyriakos
I did try it. Node works fine even though I didn't do anything exotic on it.

------
manyxcxi
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.

------
numo16
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](https://github.com/Microsoft/nodejs-guidelines)

------
t1amat
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.

------
wslh
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...](http://blog.coinfabrik.com/installing-copay-in-microsoft-windows/)

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.

------
vizza
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.

~~~
nailer
Which specific native modules have been a prob?

------
beeboop
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.

~~~
NoGravitas
'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.

~~~
beeboop
I was honestly in disbelief when I first came across it. It just seems
insanely stupid on so many levels.

~~~
jakub_g
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

------
bleuarff
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.

------
jakub_g
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.

------
smhg
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.

~~~
nailer
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.

------
kyriakos
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.

------
sabarn01
Works pretty well. There are some npm packages that don't work with windows.
[subst](
[https://www.microsoft.com/resources/documentation/windows/xp...](https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-
us/subst.mspx?mfr=true)) solves the path issue. Also with bash on windows in
the future it shouldn't be any issue.

------
mkozlows
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.

~~~
happyslobro
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.

------
patates
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.

------
tym0
You could still use Docker or a vagrantbox if you ever encounter problems.

------
bluepill
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.

