node.js - Node npm windows file paths are too long to install packages

Question

Situation

I want to use gulp and related front-end tool chains in Windows-hosted development environments. I'm hitting a wall trying to use gulp plug-ins like Browser-Sync, because the node_modules folder graph fans out making the windows file paths too long to copy the files. I'd like a pragmatic approach for handling this problem right now on Windows, irrespective of what the Node community may or may not provide to improve npm usability on the Windows in the future.

2 Questions

1. Is there an npm workflow for Windows that just works the way it was intended? "run the command and the files install" (e.g. comparable to npm on OSX, npm on Linux, ruby gems or even nuget) I don't want to fiddle with a bunch of manual file edits, symlinks, etc. every time I use npm on Windows.

2. Is there a well-documented, stable Cygwin workflow for npm and node execution to workaround the Windows API file path limits?

Gory details listed below...

General Problem

• Running npm install from a standard Windows command prompt fails on deeply nested node_modules hierarchies.
• Per Joyent's github repo thread, this is an acknowledged issue with no palatable workarounds for developers in Windows-centric environments. (Really?)
• NT Kernel supports file path lengths up to 32,767 characters.
• Windows API's MAXPATH is limited to 260 characters.
• Windows API handles file operations for all major Windows shells and whatnot including: Explorer, CMD, Powershell,MYSgit bash, etc. (MS really? How long has NTFS been around?)
• Cygwin supports long file paths, but npm.cmd doesn't work out-of-box due to crlf formatting. I tried the DOS2Unix transform on npm to get it working with Cygwin, but there seem to be other issues with this.

My Current Hack

• Create an "n" folder as a staging area on the root of C:, because this shortens my folder path.
• Run npm inside the "n" folder to install modules for whatever I need.
• Fire up Cygwin and use cp to copy the node_modules folder into a destination project.
• Rinse and repeat when dependencies change or when I need to spin up a new project.

Other Unpalatable Workarounds

Symbolic Links can be used to shorten file paths, but these are kludgy hacks. As the npm ecosystem grows, nested dependency chains will become too long and this workaround become unusable.

Adding ALL dependences to the root folder's package.json file was mentioned in one thread I came across. Although this approach will flatten the folder structure and prevent loading of duplicate modules, this workaround feels unnatural. It also kills the usability, durability, and productivity of npm, because you have to fiddle with files and folders post-install either manually or with some hacky scripts. The approach is also vulnerable to the same fate that Symbolic Links approach may eventually suffer.

Answer 1

The problem with deeply nested folders on Windows has been mostly solved starting with npm version 3.x.

According to npm:

.npm@3 makes the install "maximally flat" by hoisting everything it can to the top level node_modules. This means nesting only occurs on conflicts and as such, trees should never get very deep. As such, the windows path length limitation shouldn't be run into.

I have just installed npm 3.1.0 and tried it out on a package that was throwing the dreaded The specified path, file name, or both are too long error.

The problem went away.

You can get the latest npm builds from here : npm releases