Hacker News Reader

Comment by MichaelGG | Hacker News Reader

Wow this looks pretty amazing!

How do you handle the super-long paths npm is so fond of? On Windows I often run into issues when searching or trying to manipulate a solution containing anything npm due to too-long paths.

View on HN

We try to mitigate the issue in a few ways:

1) warnings when you hit max_path that offer to run 'npm dedupe'

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) patiently await a flat node_modules directory - http://blog.npmjs.org/post/111968476155/npm-weekly-6

4) groan very loudly when it happens - no good keeping those emotions bottled up ;-)

luckily #1/#2 cover most cases

If you use git, open a git bash window and do it from there. If you don't use git, install cygwin and do it from a cygwin bash window. Both are *nix-simulated shells and are not subject to the MAX_PATH limit. I do most of my command line work using Power Shell, but I always have a git bash terminal ready for npm, jspm and other similar path-length-affected tools.

I have run into this problem as well. Manually modifying packages is not fun.

See my comment above, but if you do this frequently... we have a feature that enables you to right click on an installed npm package in the npm tree in Solution Explorer and open the relevant folder in explorer

I use a tool called flatten-packages [1] and I usually do all of my npm work while visual studio is closed (and use short root paths as mousetraps suggested). I just flatten them after adding/updating/syncing packages.

[1] https://www.npmjs.com/package/flatten-packages

That's worked well for me, too. The biggest problem with long file paths is the deeply nested dependencies, so flatten-packages handles it for me.

Reply on news.ycombinator.com