Live data from Hacker News

Node's nested node_modules approach is basically incompatible with Windows

github.com

61–62 of 62 posts

Re: Node's nested node_modules approach is basically incompatible with Windows

#61
post #25

What 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 wa…

Fair enough, makes sense from the C perspective.

Re: Node's nested node_modules approach is basically incompatible with Windows

#62
post #39
post #36

Earlier quoted context omitted.

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

I'm not sure we are talking about the same thing: I was talking about runtime state (think: singleton instances). A directory wouldn't solve that problem.
Post reply on HN