5 ms·

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 manipul

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.

AdeptusAquinas 12y ago
I have run into this problem as well. Manually modifying packages is not fun.
- mousetraps 12y ago
  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
mousetraps 12y ago
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 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
WorldWideWayne 12y ago
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 https://www.npmjs.com/package/flatten-packages
- jongalloway2 12y ago
  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.
axefrog 12y ago
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.

AdeptusAquinas 12y ago

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

mousetraps 12y ago
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

mousetraps 12y ago

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

WorldWideWayne 12y ago

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 https://www.npmjs.com/package/flatten-packages

jongalloway2 12y ago
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.

axefrog 12y ago

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.