3 ms·

> while everyone claims node's dependencies are hell, I love the choice available (although over time, it's tiring). So... at one place I work, we use nodejs.

by vacri 10y ago

> while everyone claims node's dependencies are hell, I love the choice available (although over time, it's tiring). So... at one place I work, we use nodejs. There are so many modules added using so many files, that we ended up not being able to use our packaged application - extracting the package into a holding dir before moving into place meant that we ran out of inodes on the filesystem (stock 8GB ubuntu ext4 cloud image)! The filesystem could not hold two copies of our app, basically, due to inode exhaustion. The easy workaround was "increase the size of the disk", which seems silly given it's 80% free space. This has apparently been fixed in recent times with flatter npm structures, but watching the nodejs community run into every single packaging roadblock that has been solved before is just disheartening.

Daishiman 10y ago
Seriously, Node has been the worst platform when it comes to managing its ridiculous (in a bad way) ecosystem of packages where there's no standardized solution for anything.
nailer 10y ago
> watching the nodejs community run into every single packaging roadblock that has been solved before is just disheartening. Deeply nesting packages was specifically designed to fix the issue that other packaging systems have: two dependencies needing different versions of a third dependency. Flat-where-possible structures (ie, npm v3 and up) were designed to improve this. They're excellent and npm is the only place I've seen them.
ohstopitu 10y ago
I had this issue initially when I was developing on Windows. We hit the limit of Windows's 255 char file path limit. We also have had issues with node_modules takes minutes to download to the point that we basically had to cache it in our CI builds - which in itself was a really bad idea (thankfully Yarn seems to fix a lot of those issues)
- douche 10y ago
  Seriously. NPM/bower downloads are at least 50% of our CI build time - which also includes compiling a largish C# solution, running unit tests, generating PDF documentation, building an installer, and putting everything through ReSharper code inspections. That's when those download/install steps don't just fail for some unrecorded reason.

by vacri 10y ago

Daishiman 10y ago

Seriously, Node has been the worst platform when it comes to managing its ridiculous (in a bad way) ecosystem of packages where there's no standardized solution for anything.

nailer 10y ago

> watching the nodejs community run into every single packaging roadblock that has been solved before is just disheartening. Deeply nesting packages was specifically designed to fix the issue that other packaging systems have: two dependencies needing different versions of a third dependency. Flat-where-possible structures (ie, npm v3 and up) were designed to improve this. They're excellent and npm is the only place I've seen them.

ohstopitu 10y ago

I had this issue initially when I was developing on Windows. We hit the limit of Windows's 255 char file path limit. We also have had issues with node_modules takes minutes to download to the point that we basically had to cache it in our CI builds - which in itself was a really bad idea (thankfully Yarn seems to fix a lot of those issues)

douche 10y ago
Seriously. NPM/bower downloads are at least 50% of our CI build time - which also includes compiling a largish C# solution, running unit tests, generating PDF documentation, building an installer, and putting everything through ReSharper code inspections. That's when those download/install steps don't just fail for some unrecorded reason.