I'm surprised the obvious solution isn't already implemented universally by package managers: checkout the modules into a single directory, named as "[name]-[commit SHA]". You get all the benefits of the current system, with the added benefit that if A and B both turn out to want to check out C#1a029fb, then you only get one copy.
Node's nested node_modules approach is basically incompatible with Windows
31–40 of 62 posts
Re: Node's nested node_modules approach is basically incompatible with Windows
#32So far I've been able to get by in Windows (for my projects at least) if I use Cygwin for interacting with paths that are longer than MAX_PATH. For example - if a project has node_modules committed in git then I have to clone the repo using Cygwin. This doesn't help with the problem related to install scripts on deeply nested components though because npm doesn't support Cygwin. In Windows I still run npm and node commands in a regular command prompt.
Re: Node's nested node_modules approach is basically incompatible with Windows
#33Long paths are a PITA on Windows sometimes :(. A while ago I had a problem with long node module paths and msysgit. Luckily, this was fixed in v1.9.0
Re: Node's nested node_modules approach is basically incompatible with Windows
#34isnt it the reason why python ,ruby and co install themself in /c/ by default? I always wondered why they did that. PHP and Java dont have this problem(but "hello" package conflicts...).
Re: Node's nested node_modules approach is basically incompatible with Windows
#35Have the same problem. Although I'm a Mac user, but I'm using OneDrive to store some toy projects. OneDrive stopped working and complained about the long folder path when I tried to install a NPM package. After some researches, I know this problem will not be fixed soon and move all of my Node projects to DropBox. For Windows user, I think the only solution now is to use a VM.
Re: Node's nested node_modules approach is basically incompatible with Windows
#36I'm surprised the obvious solution isn't already implemented universally by package managers: checkout the modules into a single directory, named as "[name]-[commit SHA]". You get all the benefits of the current system, with the added benefit that if A and B both turn out to want to check out C#1a029fb, then you only get one copy.
That benefit would be a breaking change. Node modules are stateful, so two packages suddenly sharing their dependency could have nasty side effects.
Re: Node's nested node_modules approach is basically incompatible with Windows
#37This 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 t…
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.
Re: Node's nested node_modules approach is basically incompatible with Windows
#38Earlier quoted context omitted.
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.
Re: Node's nested node_modules approach is basically incompatible with Windows
#39I'm surprised the obvious solution isn't already implemented universally by package managers: checkout the modules into a single directory, named as "[name]-[commit SHA]". You get all the benefits of the current system, with the added benefit that if A and B both turn out to want to check out C#1a029fb, then you only get one copy.
That benefit would be a breaking change. Node modules are stateful, so two packages suddenly sharing their dependency could have nasty side effects.
Eek, I didn't realize anyone thought it was a good idea for modules to be holding state inside themselves.
Simple-enough fix, though: drop an extra directory in there, call it "state", and have each state-container in that dir be named after the the hash of the dependency path you would have traversed to load it. Virtualize modifications to packages into those state-containers.
(This is also pretty much how Windows protects itself from programs that think keeping their state in the Program Files directory is a good idea.)
Re: Node's nested node_modules approach is basically incompatible with Windows
#40Earlier quoted context omitted.
> second one is nodejs dependency on what google does/doesnt do,since google maintains V8 Google maintaining V8 is one of the big reasons why Node has been successful. There is no way an independent Node.JS foundation would have the resources to optimize and test JS like the Chrome team. So far, the problems have been minor and V8 has done a decent job keeping up with upcoming JS standards. So this isn't a problem. >…
I wonder why Mozilla didnt/couldnt jump in the ship and propose a viable alternative to node/V8,I know there is a node/spidermonkey project somewhere but it isnt maintained. V8 api changes made a lot of binary modules break and it will happen again,so it is a problem on the long run.Of course NodeJS team cant maintain V8. But please dont throw that problem under the carpet,It's a real issue. > Google maintaining V8 i…
There exists "gjs" and "js" ("smjs" in Debian), both of which are being maintained.