Know the biggest issue I've had with Node (well not me, but my colleagues)? That modules have a habit of using symlinks, which break horridly across Vagrant/VirtualBox shared folders. We ended up fixing it somewhat by using the --no-bin-links option on `npm install` and swapping over to SSHFS, but I really wish module writers would pay more attention to Windows... one of Node's strengths is that it works pretty darned well on Windows (just like how XAMPP made PHP deal with windows well enough for a large developer base to grow)
I am somewhat surprised at this topic. Of all the the issues Node.js has on windows, this seems like a fairly minor one. In my eyes, the biggest issue is simply this:<p>A lot of module writers don't care about Windows.<p>A big part of the node ecosystem is that there is a module for practically anything. While node core has great support for windows, and also helps aid developers in writing code that is windows compatible, from what I have seen, its not often followed.<p>Any number of simple things break modules on windows, using a '/' as a path separator instead of path.join, native modules, bash or shell scripts used in pre- or post-install scripts and probably a hundred other small ways to screw it up. Even trying to make your own module Windows compatible is often thwarted by a dependency that doesn't. Like Java's promise of "Write once, run anywhere", its a great idea, but hasn't completely panned out.<p>I really hope that as the node community matures, there can be more of a focus on making sure things work on Windows. Node is a great platform partially because of all those modules and getting them all working will make writing cross platform apps and services a heck of a lot easier.
I actually find it surprising how many people feel recursive node_module dependency folders is justified. It seems absolutely the worst possible solution to me. Am I misunderstanding something about this. Is there any reason Bundler's approach doesn't work here?<p>It seems ridiculous to me how many folders are created when I just need a couple of node modules to do something.
This is going on a bit of a tangent, but even Visual Studio used to run up against this problem all the time using some of Microsoft's own libraries. It was laughable at the time, but some of Microsofts teams (<i>cough</i> Patterns & Practices <i>cough</i>) loved to created DLLs with huge long namespaces. That coupled with the fact that Visual Studio projects were created in /Users/User.Name/Visual Studio/Visual Studio ##/Projects/ to begin with created a lot of problems.<p>As a result I almost always put all my projects at the root something like /src to reduce the odds of running into these problems.
The title looks exaggerated. I thought NodeJS cannot just run on Windows anymore. It's not the case though, it does - it's just it creates folders that are nested.
I'm surprised the obvious solution isn't already implemented universally by package managers: checkout the modules into a single directory, named as "[name]-[commit SHA]". You get all the benefits of the current system, with the added benefit that if A and B both turn out to want to check out C#1a029fb, then you only get one copy.
The Win32API was initially designed to make it very easy to port from Win16API in the early 1990s. Microsoft neglected to improve the Win32API starting with the dotNet adventures. Instead of an improved Win64API we have the identical API for 32 and 64 bit (and WinRT API).
The shell still doesn't support UNC path. The Windows NT series operating system would support different subsystems other than Win32.<p><i>Naming Files, Paths, and Namespaces</i> on MSDN explains the details: <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...</a>
Have the same problem. Although I'm a Mac user, but I'm using OneDrive to store some toy projects. OneDrive stopped working and complained about the long folder path when I tried to install a NPM package. After some researches, I know this problem will not be fixed soon and move all of my Node projects to DropBox. For Windows user, I think the only solution now is to use a VM.
Windows does support long paths (up to about 32k characters): Here is a good explanation from the .net perspective (but the same holds for non-managed APIs): <a href="http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx" rel="nofollow">http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-path...</a><p>Long paths are just most ugly to use:
"Long paths with the \\?\ prefix can be used in most of the file-related Windows APIs, but not all Windows APIs. For example, LoadLibrary, which maps a module into the address of the calling process, fails if the file name is longer than MAX_PATH. So this means MoveFile will let you move a DLL to a location such that its path is longer than 260 characters, but when you try to load the DLL, it would fail. There are similar examples throughout the Windows APIs; some workarounds exist, but they are on a case-by-case basis."
Long paths are a PITA on Windows sometimes :(. A while ago I had a problem with long node module paths and msysgit. Luckily, this was fixed in v1.9.0<p><a href="http://pingec.si/blog/articles/msysgit-longpath/" rel="nofollow">http://pingec.si/blog/articles/msysgit-longpath/</a>
The easiest solution I've found is to just run a VM and not sync whatever folder you install node_modules in. I just had this problem like a week ago with gulp because I was syncing the folder I was building in. It's a good time to learn how to use Vagrant.
So far I've been able to get by in Windows (for my projects at least) if I use Cygwin for interacting with paths that are longer than MAX_PATH. For example - if a project has node_modules committed in git then I have to clone the repo using Cygwin. This doesn't help with the problem related to install scripts on deeply nested components though because npm doesn't support Cygwin. In Windows I still run npm and node commands in a regular command prompt.
I ran into this yesterday, having tried to install yeoman into a folder shared between a windows host and a linux vm.
Ended up with files which could not be deleted by any other way than from the windows command prompt using the 8.3 filenames.<p>An hour of swearing was enough to convince me to stop using windows for this entirely.
What percent of the node.js community will this effect?<p>What's the design reason for Windows tools to only have a max of 260 file path chars? If it's not the OS, but the tools he is using, why not use tools that work? Isn't this the tools bug?<p>Honestly, if he is doing web development, his life will be easier with a linux distro.
isnt it the reason why python ,ruby and co install themself in /c/ by default? I always wondered why they did that. PHP and Java dont have this problem(but "hello" package conflicts...).