6 ms·

While this is an extreme case of course, packages by themselves are quite cheap (apart from installing times), and usually if the author tries to keep the depen

While this is an extreme case of course, packages by themselves are quite cheap (apart from installing times), and usually if the author tries to keep the dependencies in check it doesn't really create a mess.

joss82 10y ago
In practice though, even the smallest toy project will pull out hundred tiny dependencies. This is why funny stories like leftpadgate can happen. Relying on an external dependency is a net win if and only if the time gain overcomes the loss of control. Maybe regrouping all these tiny libraries under an umbrella project (lets call it node-utils or js-tinytools or whatever) will mitigate the problem? This project will not have any external dependency though will be used by most of the projects and ergo might be watched with much more attention.
- richthegeek 10y ago
  Grouping all these tiny libraries under an umbrella project will just end up like PHP. No consistency, and various levels of repetition and redundancy and quality. Having them separate like this at least means that if one library doesn't implement things 'right' you can switch to another easily.
  - joss82 10y ago
    PHP lacked the namespacing in the first place, which made the API messy and flat. Look at python (or ruby)'s standard library, it's awesome, and of high quality (most of the time, see urllib/requests for a counterexample).
- raverbashing 10y ago
  > Relying on an external dependency is a net win if and only if the time gain overcomes the loss of control. Everybody should remember this
- Illniyar 10y ago
  No, leftpadgate happend because you can delete packages from npm. The size of the package is irrelevent.
- jwl 10y ago
  > In practice though, even the smallest toy project will pull out hundred tiny dependencies. I had a problem with running out of inodes on my server because of the massive number of files that end up in node_modules for even a smallish project.
  - joss82 10y ago
    No kidding? This is impressive! Did you write about it somewhere?
    - jasonpbecker 10y ago
      This happens constantly on older versions of Docker.
      - BigJono 10y ago
        Another classic is installing one dependency with NPM and having it blow up because it's hit the 255 character limit for file paths on Windows due to nested dependencies.
  - erinaceousjones 10y ago
    NPM caused horrendous issues in my dev environment a while back. I was developing on a Windows 7 machine with my Node environment in a VirtualBox VM. I was keeping my code in a VirtualBox shared folder so I could edit it in my IDEs on the windows side and then easily run `npm install` etc. on the linux side. Turns out, the combination of vboxsf and ntfs masquerading as a linux filesystem is not without bugs- Sometimes, the directory depths that npm reached caused the filesystem to "soft crash", where it would just fail to do operations on files, meaning you had to run `npm install` a few times to actually grab all the dependencies. Other times, it caused the host machine to blue screen. One of the times this happened, it had the side effect of irreversibly corrupting my favourite programming font (Fira Code) for all JetBrains IDEs on that Windows install. Not so much a problem now I'm not being forced to develop in Windows. But even though I dug up bugs in unrelated pieces of software / the host OS kernel, npm was still pushing that software to the limits with that crazy recursive directory structure it was attempting to build. You don't get this shit with python!

joss82 10y ago

In practice though, even the smallest toy project will pull out hundred tiny dependencies. This is why funny stories like leftpadgate can happen. Relying on an external dependency is a net win if and only if the time gain overcomes the loss of control. Maybe regrouping all these tiny libraries under an umbrella project (lets call it node-utils or js-tinytools or whatever) will mitigate the problem? This project will not have any external dependency though will be used by most of the projects and ergo might be watched with much more attention.

richthegeek 10y ago
Grouping all these tiny libraries under an umbrella project will just end up like PHP. No consistency, and various levels of repetition and redundancy and quality. Having them separate like this at least means that if one library doesn't implement things 'right' you can switch to another easily.
- joss82 10y ago
  PHP lacked the namespacing in the first place, which made the API messy and flat. Look at python (or ruby)'s standard library, it's awesome, and of high quality (most of the time, see urllib/requests for a counterexample).
raverbashing 10y ago
> Relying on an external dependency is a net win if and only if the time gain overcomes the loss of control. Everybody should remember this
Illniyar 10y ago
No, leftpadgate happend because you can delete packages from npm. The size of the package is irrelevent.
jwl 10y ago
> In practice though, even the smallest toy project will pull out hundred tiny dependencies. I had a problem with running out of inodes on my server because of the massive number of files that end up in node_modules for even a smallish project.
- joss82 10y ago
  No kidding? This is impressive! Did you write about it somewhere?
  - jasonpbecker 10y ago
    This happens constantly on older versions of Docker.
    - BigJono 10y ago
      Another classic is installing one dependency with NPM and having it blow up because it's hit the 255 character limit for file paths on Windows due to nested dependencies.
- erinaceousjones 10y ago
  NPM caused horrendous issues in my dev environment a while back. I was developing on a Windows 7 machine with my Node environment in a VirtualBox VM. I was keeping my code in a VirtualBox shared folder so I could edit it in my IDEs on the windows side and then easily run `npm install` etc. on the linux side. Turns out, the combination of vboxsf and ntfs masquerading as a linux filesystem is not without bugs- Sometimes, the directory depths that npm reached caused the filesystem to "soft crash", where it would just fail to do operations on files, meaning you had to run `npm install` a few times to actually grab all the dependencies. Other times, it caused the host machine to blue screen. One of the times this happened, it had the side effect of irreversibly corrupting my favourite programming font (Fira Code) for all JetBrains IDEs on that Windows install. Not so much a problem now I'm not being forced to develop in Windows. But even though I dug up bugs in unrelated pieces of software / the host OS kernel, npm was still pushing that software to the limits with that crazy recursive directory structure it was attempting to build. You don't get this shit with python!