Node/npm MAX_PATH issues

[MarkStega]

There is a very well known issue with Node/NPM module management having to do with the maximum path length on Windows, see this exhausting thread: Node's nested node_modules approach is basically incompatible with Windows #6960 . So I am trying to build the new Aurelia framework (successor to Durandal and somewhat a competitor to Angular) and immediately ran into the issue when build of dependency modules failed because of the path. Is there any direction from Microsoft regarding this issue? With the seeming embrace of Node by MS having this flaw will be hurtful to adoption.

[mousetraps]

And by "direction", you mean "workaround", right? :-) There are a few options...

1. We have warnings when you install new packages that offer to run 'npm dedupe'. And now that you mention it... it would probably be good to light this up when the build fails.
2. sometimes that doesn't work, so we also suggest people start their projects in a short path like c:\src (embarassing, I know)
3. I haven't used this extensively, but some users have had success with a module called 'flatten-packages'.
4. Patiently await a flatter node_modules directory - http://blog.npmjs.org/post/111968476155/npm-weekly-6
5. groan very loudly when it happens - no good keeping those emotions bottled up ;-)

Luckily _#1/#_2 cover most cases.

One thing to be aware of with this is that dedupe, flatten-packages, and upcoming changes in npm@3 might have an adverse effect on IntelliSense due to the way the analysis engine currently analyzes dependencies. I haven't heard any complaints yet, but until we fix this, your mileage may vary.

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.)
http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx

That said... we don't like it either, and we are still thinking about what we can do.

[MarkStega]

I am absolutely new to the environment of Node/NPM so bear with me for another set of questions.
The project that I am attempting to build/run starts with the download of a source tree that has a package.json. Instructions are to run "npm install" then "jspm install -y".

I successfully created a VS nodejs solution using the "From existing NodeJS code"

1. I right clicked the npm node and executed the 'install missing packages'; I did indeed get the popup indicating that I was past the 260 character path limit. Running dedup was not sufficient. A shorter starting path won't help as the socket-io package goes many characters past 260,not just a few so Add README.md file to repository #2 won't work. I installed and ran 'flatten' and it seems that it successfully moved all of the dependencies to the 'node_modules' directory. But the flatten takes the most recent version of a package and this introduced errors when running the solution. So Code improperly indents after if block inside inline callback function #3 doesn't work. It appears that in the case of this project that Update mocha.js to correct typos #4 & Startup file not preserved after being moved to another directory #5 are the solutions that will work (hopefully).

2. Are there plans to support jspm in a similar fashion to npm?

[mousetraps]

Np, they're good questions :-)

1. After flatten, you should be able to uninstall the root package with the version conflict, and install the proper versions under the packages that need it. If you're still hitting MAX_PATH, then you can delete the node_modules folder under the new version that you installed, cross your fingers the packages in the root node_modules folder don't conflict, rinse and repeat until you've resolved all the conflicts. Basically you'll be emulating what npm@3 will be doing by creating a flat directory structure, except when there are conflicts, in which case those conflicting versions are not bubbled all the way up to the project root.
2. The cmd line should play nice with VS, but no plans to support it through UI. We can certainly discuss if you're interested in contributing. :)

[mousetraps]

Also if you want support for jspm, the web essentials extension might be another route to making it happen: http://webessentials.uservoice.com/forums/140520-general/suggestions/7136766-add-support-for-jspm

[MarkStega]

1. The flatten, although causing other issues, made finding the error in the non-flattened form easier. When I removed socket-io and redid the install I realized that the build error was not due to path depth but rather a reference to VS2010 tools (which don't exist on my development system). A simple "npm config set msvs_version 2013 --global" followed by a new copy of the source and an "npm install" produced a working sample (even if I can't examine some of the dependency tree).

2. Thanks for the JSPM/Web Essentials thought; For now, the command line is not too onerous.

[phillipwei]

I was battling with path issues. I found that, for my situation, the following didn't work:

• using a shorter directory.
• dedupe
• flatten-package.
• npm install -g.

The only thing that did work was to install, trigger the path error, and use that to locate the most common offending module; uninstall; and then re-install the common module first.

There is no good way around it on Windows. Making paths shorter either through global install or subst or renaming are all hacks and do not address the issue. Sooner or later you'll run into a situation when none of those work. The only solution as of now is move away from developing in node on Windows as Node is not fully compatible with it. Period. It is best to migrate sooner rather than later to avoid running into this issue when the project is at a stage when moving to a different OS can cause a lot of headache ...

[glen-84]

Related: https://github.com/dotnet/corefx/issues/645

[itanex]

@mousetraps with npm@3.1.1 recently released the long path issue is expected to be resolved or at least mitigated by how packaging is applied into the node_module folder. Since it is still a bit beta-ish, you have to use npm version specific update. This creates a confusing aspect in the VS solution display now.

As expected a package in this folder not in the package.json file displays as &<package>@version (not listed in package.json) This presents a confusing aspect now as the previous expected result fulfilled the need for excessive unreferenced dependencies.

[mousetraps]

@itanex see #233. We're working on it :-)