4 ms·

<rant> npm (and the CommonJS module system) is the #1 reason I use Node.js. I don't care if Javascript is ugly, npm totally makes up for it. I don't get why mo

by sysk 12y ago

<rant> npm (and the CommonJS module system) is the #1 reason I use Node.js. I don't care if Javascript is ugly, npm totally makes up for it. I don't get why most module systems implicitly import symbols in the scope (Python, Ruby) or worse, those that pollute the global scope (PHP). Brew (Ruby) is not that bad but Python's package ecosystem is a complete mess (distutils, setuptools, pip, etc.). Cabal (Haskell) is pretty good too in comparison to C/C++ (installing dependencies usually involves following instructions in a README file, that is, if there are available instructions for your OS). I haven't tried Go. I believe the language of the future will be built around, and win mainly because of, its package system/ecosystem. </rant>

ploxiln 12y ago
<rant> npm is easily the worst. Python is a lot better. I hold the C library model as the golden standard, so we're not going to see eye-to-eye. The worst part of npm is the sub-dependencies. Having enabled them, they proliferate endlessly. Each time I improve the efficiency of deploying a strictly controlled tree of modules, the front-end devs manage to double the number in use. 200, 350, 650, over 1000... oh and these improvements come from realizing that npm-shrinkwrap isn't 100% reliable, and ending up with scripts comparing npm-ls output and doing full wipe and replace with a tarball for even the slightest change to the dependency tree. If some serious bug is discovered in one of these things, there's no way the 20 copies of it at various levels of this tree of 1000 modules are going to get patched. No one really has a handle on what's in these hundreds of megs of various versions of modules. This is the true fast code movement - serious problems can't be fixed in there, they'll just be ignored and replaced with other bugs in the twice-yearly full rewrite. Don't get me wrong, our frontend devs are among the best I've seen, but the pressures and environment they're in make them focus on churning out the latest fad in web design and skimping on engineering quality everywhere possible. Python doesn't do implicit import of symbols into a scope if you don't use "from blah import (star)". Don't use the (star). Managing, and using, a list of python modules, each at a particular version, is way simpler, more reliable, and more efficient (than npm style). Pip can reliably list installed module state (freeze) and install from source tarballs or git tag checkout. You need to fully control and understand the versions of all libraries installed and used on a system in order to have a fully reproducible deployment state, and be able to reliably roll back to a previous state. Given that, the Python or C model is much easier to work with. </rant>
- NateDad 12y ago
  Go's model is pretty good. This is why there's just a single $GOPATH and every package has exactly one location on disk, so even if 100 dependencies use the same subdependency... you only have to update one spot if it needs a patch. And again, this only needs to be done at development time. It's baked in when you compile, and from there on, deployment is just a file copy of your binary. No dependencies during deployment.
  - notduncansmith 12y ago
    Maybe I'm missing something, but this seems like a bad idea to me. What if projects are relying on differing versions of the same package? What if two developers collaborating on the same project have different versions of that dependency installed? Sure, it's space-efficient, but disk is cheap, and developer hours are expensive. I certainly wouldn't want two employees burning man-hours trying to figure out why some app is behaving differently on their respective machines, only to fix the problem and unwittingly break another project in the most expensively subtle of ways. I'd really like to think I'm missing something though, I certainly don't presume to be more insightful than the collective Go team.
    - ploxiln 12y ago
      There's a philosophical disagreement here. It's true, developers are expensive. But I think it's a fallacy that what's less efficient for a computer is better for a developer. The npm-style dependency tree enables and encourages much more complexity, which developers then have to deal with when debugging or deploying. They need new tools to help them get a handle on the huge number of modules. That's more expensive than a system kept more "under control".
      - notduncansmith 12y ago
        > I think it's a fallacy that what's less efficient for a computer is better for a developer. I don't think that was ever said; I claimed that trading disk space for developer hours is a good trade-off in this case. > The npm-style dependency tree enables and encourages much more complexity, which developers then have to deal with when debugging or deploying. I don't believe this is the case. When developing an app (as opposed to a library) it's considered a best practice to check your node modules into source control, ensuring that there's never a mismatch between installed dependencies on developer machines. If you don't want to do that, you take what comes - but even before I picked up on that, I never ran into issues even when collaborating with 5+ developers. You just need to make sure your package.json locks your versions appropriately.
NateDad 12y ago
FWIW, Go namespaces everything by default, so if you import a package called foo, all types, functions, etc from that package are namespaced by foo, i.e. "foo.whatever" The thing I love about Go's packaging is that your VCS and package manager are the same thing. There's no need to wonder where the code from package foo comes from... because you know you imported it from github.com/jimbob/foo It also means there's no fighting over namespaces, since it's just done by domain name (i.e. I can have the package npf.io/foo because I control that domain, and I don't have to to fight over who gets to use that name).
notduncansmith 12y ago
Hear, hear! npm is without a doubt the best module system I've come across in my years of development. RubyGems is kind of a pain, .NET dependency management is a joke, Python is super fragmented, and Go doesn't have one. Godeps is an okay tool, and `go get` is cute, but I have yet to use a package manager that couldn't stand to borrow a thing or two from npm.

by sysk 12y ago

ploxiln 12y ago

<rant> npm is easily the worst. Python is a lot better. I hold the C library model as the golden standard, so we're not going to see eye-to-eye. The worst part of npm is the sub-dependencies. Having enabled them, they proliferate endlessly. Each time I improve the efficiency of deploying a strictly controlled tree of modules, the front-end devs manage to double the number in use. 200, 350, 650, over 1000... oh and these improvements come from realizing that npm-shrinkwrap isn't 100% reliable, and ending up with scripts comparing npm-ls output and doing full wipe and replace with a tarball for even the slightest change to the dependency tree. If some serious bug is discovered in one of these things, there's no way the 20 copies of it at various levels of this tree of 1000 modules are going to get patched. No one really has a handle on what's in these hundreds of megs of various versions of modules. This is the true fast code movement - serious problems can't be fixed in there, they'll just be ignored and replaced with other bugs in the twice-yearly full rewrite. Don't get me wrong, our frontend devs are among the best I've seen, but the pressures and environment they're in make them focus on churning out the latest fad in web design and skimping on engineering quality everywhere possible. Python doesn't do implicit import of symbols into a scope if you don't use "from blah import (star)". Don't use the (star). Managing, and using, a list of python modules, each at a particular version, is way simpler, more reliable, and more efficient (than npm style). Pip can reliably list installed module state (freeze) and install from source tarballs or git tag checkout. You need to fully control and understand the versions of all libraries installed and used on a system in order to have a fully reproducible deployment state, and be able to reliably roll back to a previous state. Given that, the Python or C model is much easier to work with. </rant>

NateDad 12y ago
Go's model is pretty good. This is why there's just a single $GOPATH and every package has exactly one location on disk, so even if 100 dependencies use the same subdependency... you only have to update one spot if it needs a patch. And again, this only needs to be done at development time. It's baked in when you compile, and from there on, deployment is just a file copy of your binary. No dependencies during deployment.
- notduncansmith 12y ago
  Maybe I'm missing something, but this seems like a bad idea to me. What if projects are relying on differing versions of the same package? What if two developers collaborating on the same project have different versions of that dependency installed? Sure, it's space-efficient, but disk is cheap, and developer hours are expensive. I certainly wouldn't want two employees burning man-hours trying to figure out why some app is behaving differently on their respective machines, only to fix the problem and unwittingly break another project in the most expensively subtle of ways. I'd really like to think I'm missing something though, I certainly don't presume to be more insightful than the collective Go team.
  - ploxiln 12y ago
    There's a philosophical disagreement here. It's true, developers are expensive. But I think it's a fallacy that what's less efficient for a computer is better for a developer. The npm-style dependency tree enables and encourages much more complexity, which developers then have to deal with when debugging or deploying. They need new tools to help them get a handle on the huge number of modules. That's more expensive than a system kept more "under control".
    - notduncansmith 12y ago
      > I think it's a fallacy that what's less efficient for a computer is better for a developer. I don't think that was ever said; I claimed that trading disk space for developer hours is a good trade-off in this case. > The npm-style dependency tree enables and encourages much more complexity, which developers then have to deal with when debugging or deploying. I don't believe this is the case. When developing an app (as opposed to a library) it's considered a best practice to check your node modules into source control, ensuring that there's never a mismatch between installed dependencies on developer machines. If you don't want to do that, you take what comes - but even before I picked up on that, I never ran into issues even when collaborating with 5+ developers. You just need to make sure your package.json locks your versions appropriately.

NateDad 12y ago

FWIW, Go namespaces everything by default, so if you import a package called foo, all types, functions, etc from that package are namespaced by foo, i.e. "foo.whatever" The thing I love about Go's packaging is that your VCS and package manager are the same thing. There's no need to wonder where the code from package foo comes from... because you know you imported it from github.com/jimbob/foo It also means there's no fighting over namespaces, since it's just done by domain name (i.e. I can have the package npf.io/foo because I control that domain, and I don't have to to fight over who gets to use that name).

notduncansmith 12y ago

Hear, hear! npm is without a doubt the best module system I've come across in my years of development. RubyGems is kind of a pain, .NET dependency management is a joke, Python is super fragmented, and Go doesn't have one. Godeps is an okay tool, and `go get` is cute, but I have yet to use a package manager that couldn't stand to borrow a thing or two from npm.