Hacker News Reader

Comment by dbbolton | Hacker News Reader

This definitely seems more like a Windows issue than a Node issue.

At first I agreed with you; but then I read one of the comments on github that swayed me.

"You are the one playing games - calling core parts of Windows like Explorer "3rd party tools", and suggesting that not supporting long paths is a bug. Microsoft have made it clear repeatedly that non-support for long paths is not a bug, and not something that will change.

A package manager creating paths that do not work with the majority of the software written for an OS, then claiming compatibility with the OS, is playing games, at your users expense."

At the end of the day Windows wont be the thing changing. haha.

I don't follow, should we then rename everything to cryptic, short characters like some people do in MongoDB (as someone suggested using n_m instead of node_modules)? If it works well in other platforms, it's an issue with that specific platform

windows has path length limits. Figure out how to live in them, whatever way is best. If that means using cryptic names, then do it. cryptic folder names, while not a good thing, are extremely common in windows.

Or, don't support Windows.

Yes, fine by me.

I think we're arguing different things. I'm more talking semantics.

Right, in practical terms it's up to Node to fix this (or go extreme and drop Windows support), but in a more abstract sense I still blame Microsoft for such a glaring design flaw in their software that they are unwilling/unable to fix.

Microsoft can decide to not call it a bug but that doesn't mean the rest of us don't believe it's a bug.

In that case Node.js has a huge bug - only natively supporting one messy legacy language (without crap-transpilation).

Is creating dozens of nested folders inside each other really a sane thing to do? Run `find .` on any reasonably complicated node project and look at the crazy paths that show up.

npm's strategy of nesting like that made things simpler when it was more of a new project, but it's time to come up with something more robust.

This; each subproject having its own nested string of (often the same) dependencies just seems wasteful of me.

I like Maven's approach better; a centralized repository directory. In Node / NPM's case, given that each library has a simple name, I can imagine a directory structure ~/.node_modules/package/1.0.0. Severely reduces filesystem depth, and probably fixes re-downloads of the same package / versions too. Only requirements are a rewrite or update of node's require method, NPM's package install directory and maybe some more strictness about NPM releases.

I disagree. I think node's approach is easily understandable, and quite robust. It's incredibly easy to dive down the dependency chain and see every package, and know exactly which one is being used where. Not something that can be said about package managers that use the flattened approach.

Pretty Printing the full dependency tree is a feature that could be easily added to npm itself, and in a way easier way to understand than trying to read through a directory tree

Reply on news.ycombinator.com