Entering my serious vote to end node development on windows
Node's nested node_modules approach is basically incompatible with Windows
21–30 of 62 posts
Re: Node's nested node_modules approach is basically incompatible with Windows
#22Know the biggest issue I've had with Node (well not me, but my colleagues)? That modules have a habit of using symlinks, which break horridly across Vagrant/VirtualBox shared folders. We ended up fixing it somewhat by using the --no-bin-links option on `npm install` and swapping over to SSHFS, but I really wish module writers would pay more attention to Windows... one of Node's strengths is that it works pretty darned well on Windows (just like how XAMPP made PHP deal with windows well enough for a large developer base to grow)
Re: Node's nested node_modules approach is basically incompatible with Windows
#23Earlier quoted context omitted.
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…
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
I think we're arguing different things. I'm more talking semantics.
Re: Node's nested node_modules approach is basically incompatible with Windows
#24Was the recursive "every package include its dependencies" done just because it was easier? Or was it a conscious design choice.
Well at least there is no possibility of conflicts(unlike some other pm). The problem is people writing modules that have like 1 function while requiring 10 other modules that have just 1 function themself that require 10*10 other modules ... Of course it doesnt scale,and of course the package manager wont scale either... But it's not a NodeJS problem it is a NPM problem.NodeJS has other problems though(the lack of g…
As far as I understand it the problem _is_ with Node -- specifically module.js [0] which is what defines require() and its recursive lookup behavior.
[0] https://github.com/joyent/node/blob/master/lib/module.js
Re: Node's nested node_modules approach is basically incompatible with Windows
#25What percent of the node.js community will this effect? What's the design reason for Windows tools to only have a max of 260 file path chars? If it's not the OS, but the tools he is using, why not use tools that work? Isn't this the tools bug? Honestly, if he is doing web development, his life will be easier with a linux distro.
>What's the design reason for Windows tools to only have a max of 260 file path chars?
So in C you can just say `char buff[MAX_PATH] = {0};` and not worry about heap allocation.
That's also the reason why it can't ever be extended - because MAX_PATH is compiled into every binary and you would create instant buffer overflow vulnerabilities in a lot of software.
It was a reasonably good idea at the time the decision was made.
Re: Node's nested node_modules approach is basically incompatible with Windows
#26Know the biggest issue I've had with Node (well not me, but my colleagues)? That modules have a habit of using symlinks, which break horridly across Vagrant/VirtualBox shared folders. We ended up fixing it somewhat by using the --no-bin-links option on `npm install` and swapping over to SSHFS, but I really wish module writers would pay more attention to Windows... one of Node's strengths is that it works pretty darne…
[deleted]
Re: Node's nested node_modules approach is basically incompatible with Windows
#27Know the biggest issue I've had with Node (well not me, but my colleagues)? That modules have a habit of using symlinks, which break horridly across Vagrant/VirtualBox shared folders. We ended up fixing it somewhat by using the --no-bin-links option on `npm install` and swapping over to SSHFS, but I really wish module writers would pay more attention to Windows... one of Node's strengths is that it works pretty darne…
There's no reason why node/npm can't implement a thin filesystem mapping layer on Windows and map long, logical module paths to shorter filesystem paths. That sort of address translation would fix both the symlink and the path length issues.
Re: Node's nested node_modules approach is basically incompatible with Windows
#28This definitely seems more like a Windows issue than a Node issue.
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.
Re: Node's nested node_modules approach is basically incompatible with Windows
#29Earlier quoted context omitted.
Well at least there is no possibility of conflicts(unlike some other pm). The problem is people writing modules that have like 1 function while requiring 10 other modules that have just 1 function themself that require 10*10 other modules ... Of course it doesnt scale,and of course the package manager wont scale either... But it's not a NodeJS problem it is a NPM problem.NodeJS has other problems though(the lack of g…
> 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 is one of the big reasons why Node has been successful.
Sure,but it doesnt guarantee Nodejs survival on the long run.Look, nodejs is an awesome project,i'm not here to question that fact.I use nodejs everyday I love it.I just cant trust Google on anything on the long run.
Do V8 team consult with nodejs team,listen to their suggestion ? (that a question).Is it a bidirectional relationship or a unilateral one?
Re: Node's nested node_modules approach is basically incompatible with Windows
#30Earlier quoted context omitted.
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…
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.