4 ms·

> Are people really making projects with dozens (hundreds? more?) of dependent libraries? Yes. > Are there aspects of the language or runtime that reward mul

> Are people really making projects with dozens (hundreds? more?) of dependent libraries? Yes. > Are there aspects of the language or runtime that reward multiple layers of configuration management? A significant fraction of the node community likes to split their project into really, really small packages and treat them as if they're independent even if they come from the same source repo and tend to get used together. As an example, the popular collection processing library Lodash publishes a package for each method and people actually do depend on individual methods. There are two major rationales for this. The first is that JS is a dynamic language and in dynamic languages, smaller chunks of code are easier to reason about than larger ones. The second is that the JS community as a whole cares more about artifact size than pretty much any other community. Having smaller packages allows you to produce a smaller payload without having to rely on techniques like tree shaking. I find micro packages maddening but people give me their code for free and it mostly works so I don't complain about it that much.

erikpukinskis 10y ago
What do you find maddening about micro packages? I hate depending on a giant stack of frameworks (slowing installs, builds, adding behavior surface area) when I just need a function or two, so micro packages are a joy for me.
- tigershark 10y ago
  Reading the article it seems to me that this micro packages approach is what slows down everything. I never, ever have seen all these problems in even not-so-state-of-the-art dependency managers like maven or nuget. Seriously up to now it was impossible to have a build server isolated from the internet if you didn't want to check-in all the dependencies??? Simply crazy. I really can't understand how people can even think to use a dependency manager system that doesn't satisfy the essential requirement of having your CI server sandboxed.
  - happyslobro 10y ago
    Where would a CI server retrieve dependencies from, if not either over the network, or from within the repository? Do you keep a module / library cache on the CI server itself? In other words, what do supply as input to your CI process, besides a Git URL?
    - tigershark 10y ago
      In a local nexus/nuget repository in the intranet, for sure I'm not allowing internet access directly from a CI server. And apart from the obvious and scary security concerns it is also much faster.
      - happyslobro 10y ago
        Got it. You can also set up an NPM repository like that, but I don't think that that is commonly done by small dev teams. This does lead to hilarity like the left-pad clusterfork.
  - joepie91_ 10y ago
    > Reading the article it seems to me that this micro packages approach is what slows down everything. It really isn't. The NPM client is just really, really poorly written, with no parallelization to speak of.
  - Lazare 10y ago
    > this micro packages approach is what slows down everything Not really. The npm client is just flaky, very slow, buggy, has some major design flaws in its v2 incarnation, and has a completely different set of major design flaws in its v3 incarnation. The core architecture works fine for small packages. > Seriously up to now it was impossible to have a build server isolated from the internet if you didn't want to check-in all the dependencies Of course not, although I admit the linked article implied it was if you didn't read closely. There's a wide number of solutions, including running a private registry, or a copy of the public registry, or a local cacheing proxy of the public repository, or a custom npm client that hits a local cache, etc. Some of the solutions work quite well, and in fact yarn itself is just a re-implementation of some existing solutions. > I really can't understand how people can even think to use a dependency manager system that doesn't satisfy the essential requirement of having your CI server sandboxed. As the article noted, Facebook was sandboxing their CI server and using NPM; they just didn't like the existing solutions. (Nor should they; they were a bit naff.) But that doesn't mean (nor is anyone claiming) that there were no existing solutions. Yarn looks great, but it's an extremely incremental change.
- untog 10y ago
  But a huge list of micro packages slows installs, too. It shouldn't, but NPM doesn't seem very good at parallelising operations.

erikpukinskis 10y ago

What do you find maddening about micro packages? I hate depending on a giant stack of frameworks (slowing installs, builds, adding behavior surface area) when I just need a function or two, so micro packages are a joy for me.

tigershark 10y ago
Reading the article it seems to me that this micro packages approach is what slows down everything. I never, ever have seen all these problems in even not-so-state-of-the-art dependency managers like maven or nuget. Seriously up to now it was impossible to have a build server isolated from the internet if you didn't want to check-in all the dependencies??? Simply crazy. I really can't understand how people can even think to use a dependency manager system that doesn't satisfy the essential requirement of having your CI server sandboxed.
- happyslobro 10y ago
  Where would a CI server retrieve dependencies from, if not either over the network, or from within the repository? Do you keep a module / library cache on the CI server itself? In other words, what do supply as input to your CI process, besides a Git URL?
  - tigershark 10y ago
    In a local nexus/nuget repository in the intranet, for sure I'm not allowing internet access directly from a CI server. And apart from the obvious and scary security concerns it is also much faster.
    - happyslobro 10y ago
      Got it. You can also set up an NPM repository like that, but I don't think that that is commonly done by small dev teams. This does lead to hilarity like the left-pad clusterfork.
- joepie91_ 10y ago
  > Reading the article it seems to me that this micro packages approach is what slows down everything. It really isn't. The NPM client is just really, really poorly written, with no parallelization to speak of.
- Lazare 10y ago
  > this micro packages approach is what slows down everything Not really. The npm client is just flaky, very slow, buggy, has some major design flaws in its v2 incarnation, and has a completely different set of major design flaws in its v3 incarnation. The core architecture works fine for small packages. > Seriously up to now it was impossible to have a build server isolated from the internet if you didn't want to check-in all the dependencies Of course not, although I admit the linked article implied it was if you didn't read closely. There's a wide number of solutions, including running a private registry, or a copy of the public registry, or a local cacheing proxy of the public repository, or a custom npm client that hits a local cache, etc. Some of the solutions work quite well, and in fact yarn itself is just a re-implementation of some existing solutions. > I really can't understand how people can even think to use a dependency manager system that doesn't satisfy the essential requirement of having your CI server sandboxed. As the article noted, Facebook was sandboxing their CI server and using NPM; they just didn't like the existing solutions. (Nor should they; they were a bit naff.) But that doesn't mean (nor is anyone claiming) that there were no existing solutions. Yarn looks great, but it's an extremely incremental change.
untog 10y ago
But a huge list of micro packages slows installs, too. It shouldn't, but NPM doesn't seem very good at parallelising operations.