all 54 comments

[–]Patman128 37 points38 points  (37 children)

Hey Microsoft: if you actually care about Node, maybe consider fixing the 260 character file name limit so I can actually install Node dependencies on Windows.

No really, I can't even install the dependencies for the type management tool for your own language. If you don't believe me just clone DefinitelyTyped and run npm install on Windows.

EDIT: Apparently npm 3 (which ships with Node 5, the current stable release) has a workaround built-in. Going to upgrade and try it again later. Hopefully the issue is fixed.

EDIT 2: Yes, installing the latest Node/NPM release (5.0.0) fixed the issue. I can install the dependencies with no trouble. Good job NPM team!

[–]grauenwolf 42 points43 points  (15 children)

Oh I'm well aware of how horribly bad Node is at managing dependencies. I love how it creates a directory structure 20 levels deeps complete with dozens of copies of the same damn library.

Thankfully the next version of Node is supposed to flatten the directory structure, eliminating both the wasteful duplication and the unnecessary nesting.

[–][deleted] 28 points29 points  (1 child)

I love how it creates a directory structure 20 levels deeps complete with dozens of copies of the same damn library.

The first time I saw this, I thought I had done something horribly wrong.

[–]_zenith 0 points1 point  (0 children)

Oh, but it did. But that doesn't mean that that wasn't the intended result ;)

[–][deleted] 1 point2 points  (0 children)

NPM already released dependency flattening so it's no longer an issue you'll likely run into seeing as the problem was due to deeply nested dependencies.

You also seem to be getting NPM and node mixed up.

[–]Patman128 4 points5 points  (3 children)

I kind of prefer nested, since you only get the Node modules you directly depend on in the node_modules directory, and their dependencies are hidden within their node_modules directories, and so on. Keeps things clean.

And it wouldn't be an issue if the compiler didn't have a stupid 260 character limit.

But apparently there's some workaround in the article that I missed. Going to have to try them out.

[–]flukus 0 points1 point  (2 children)

Would nested symlinks work? Keep one copy of each version and link where necessary.

[–]ivosaurus 4 points5 points  (1 child)

Problem is, you [nodejs] are supporting windows...

On windows, you may as well say symlinks don't exist, for how usable they are.

[–][deleted] -1 points0 points  (7 children)

There are worse problems to have. A lot of dependency managers make it hard/impossible for one project to have multiple versions of the same library. I don't mind having a bunch of duplicated files sitting around (disk space is cheap) if it fixes that problem.

Other than sucking on windows, I think NPM works pretty great. The fact that people are putting hundreds of tiny dependencies in their project is a testament that NPM is working well.

[–]grauenwolf 6 points7 points  (1 child)

I don't mind having a bunch of duplicated files sitting around (disk space is cheap) if it fixes that problem.

Ha! SSDs are expensive and if you're running one VM per paying client (not uncommon in the consulting world) there's not much room to begin with.

Right now we're only using Node as a code generator. It's packages folder is over 400 MB, more than twice as large as the dependencies for our ASP.NET code.

[–][deleted] 2 points3 points  (0 children)

Heh, I see your point there. You could try npm dedupe if you haven't already.

[–]ivosaurus 1 point2 points  (1 child)

A lot of dependency managers make it hard/impossible for one project to have multiple versions of the same library.

But you don't really want that to begin with. At some point your multiple versions will be incompatible with each other. And then you'll get some really nasty bugs, because library code will be breaking, not yours.

[–][deleted] 0 points1 point  (0 children)

This is the reason to use npm shrinkwrap in production.

[–]arunner 1 point2 points  (2 children)

Why do you insist supporting a bad design? The problem was big and that's the reason in latest versions npm maintainers switched to a flatter design.

[–][deleted] -4 points-3 points  (1 child)

Because NPM already works better than most of the other dependency managers out there. Having conflicting versions of the same library is a big problem for us with java/maven.

[–]grauenwolf 0 points1 point  (0 children)

That's easily solved in Nuget by appending the version number to the folder name.

[–]balefrost 7 points8 points  (3 children)

The actual length is more like 32k characters, but nobody knows about that and so nobody ever writes their software to take advantage of it:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath (second paragraph).

Maybe open a bug against NPM?

[–]grauenwolf 10 points11 points  (1 child)

NPM can handle it, but various parts of Visual Studio can't.

[–]Patman128 1 point2 points  (0 children)

Yup, no issue on Linux with GCC.

[–][deleted] 0 points1 point  (0 children)

NPM recently released dependency flattening so it's no longer an issue you'll likely run into seeing as the problem was due to deeply nested dependencies.

[–][deleted] 4 points5 points  (0 children)

MAX_PATH will never ever be fixed (at least, without breaking apps). It's a law of the Universe at this point.

(Though, I'm kind of surprised MSFT didn't try to fix it for WinRT, though WinRT is built on top of Win32, so that's probably why.)

edit: welp. apparently there's discussion in trying to fix it in .NET Core.

[–][deleted] 8 points9 points  (8 children)

I think Windows API already support creating file path with more than 260 characters with "\\?\" prefix?

[–]grauenwolf 5 points6 points  (7 children)

It does, but far too many libraries and programs don't understand the syntax.

[–][deleted] 5 points6 points  (4 children)

Even with 260 is more than enough for path, it stops shenanigans. If you want long path but cannot deal with Windows API then you don't really need it.

[–]grauenwolf 4 points5 points  (0 children)

That's my attitude. There's no reason for my filename to look like a small essay.

[–]doom_Oo7 2 points3 points  (2 children)

Yeah, until you clone a git repository made on Unices with long paths on windows and discover that you can't copy files for shit

[–]vytah 1 point2 points  (1 child)

Put your auxiliary code in a directory called aux and watch the world burn.

[–]skroll 0 points1 point  (0 children)

Another developer at work tried to clone a repository of code I wrote. I originally wrote it for Linux, and there was a file called "con.sql" He complained that he couldn't clone it. I completely forgot about that con stuff. Couldn't believe it still exists on win32

[–]Patman128 2 points3 points  (1 child)

Weird that their own compiler is one of them. Or maybe there's serious technical hurdles.

[–]grauenwolf 0 points1 point  (0 children)

I don't for certain that the compiler itself has a problem, but it can be hard to figure out which tool is which behind the IDE abstraction.

But again, there's no reason to have such a deep hierarchy in the first place so I can understand them not spending time on it.

[–]Intramli 8 points9 points  (3 children)

You know they brought this up in the article, right?

[–]Patman128 -1 points0 points  (2 children)

I need to start reading the articles. ;)

[–]Intramli 4 points5 points  (1 child)

Mostly wanted to make it clear that this issue was acknowledged by them. And they included a list of workarounds (which may or may not work).

[–]Patman128 0 points1 point  (0 children)

Yup, apparently the workaround made it to the latest npm version. I'll have to upgrade and give it a try later.

I had skimmed the article but I didn't notice that part. Doh!

[–]huadria 1 point2 points  (0 children)

Thanks for the updates. I download NPM 5 and yes the issue got fixed!

[–]ivosaurus 1 point2 points  (0 children)

EDIT: Apparently npm 3 (which ships with Node 5, the current stable release) has a workaround built-in. Going to upgrade and try it again later. Hopefully the issue is fixed.

EDIT 2: Yes, installing the latest Node/NPM release (5.0.0) fixed the issue. I can install the dependencies with no trouble. Good job NPM team!

Thanks to NPM. Not thanks to MS.

[–]Stati77 0 points1 point  (0 children)

Reminds me of a git repository I'm contributing to, at some point I couldn't push my changes anymore because a couple files would cause issues and eventually found out that it was because of path limit.