44 ms·

Having worked with Maven, Gradle, Ruby Gems, Pip and the non-existing Go package management I must say I actually really like the Node / NPM combo. I guess arti

by tnolet 8y ago

Having worked with Maven, Gradle, Ruby Gems, Pip and the non-existing Go package management I must say I actually really like the Node / NPM combo. I guess artists are their own worst critics. edit: forgot Scala's SBT, admittedly a builder using Maven repo's but still an excellent example of how bad UX in this area can get.

jonny_eh 8y ago
You'll find much harsher critics of Node/NPM in these parts! I thought Ryan did a great job of explaining his regrets without giving the impression that Node was a "mistake", is "inferior", or anything so drastic.
- allover 8y ago
  > You'll find much harsher critics of Node/NPM in these parts! They're ill-informed. GPP is correct that, for example pip is fundamentally inferior to npm [1], and those that insist on throwing shade at npm on HN should be corrected. They're wrong, and insulting a sound, well maintained project, without basis. [1] https://github.com/pypa/pip/issues/988 https://github.com/pypa/pip/issues/988
  - kbenson 8y ago
    > those that insist on throwing shade at npm on HN should be corrected. Preferrably by giving them better ammunition, since I do see NPM as substandard in quite a few ways, which is inexcusable when there do exist examples to learn from (whether it be a positive or negative influence). First, it helps to clarify whether we are talking about npm the client or NPM the repository and ecosystem. Client issues are generally easily resolved, just use a different client. For npm, this could be yarn. For cpan, this could be cpanm, or cpanplus, etc. If it's indeed the repository we are talking about, there are some obvious things that could be done to greatly improve it the NPM module ecosystem. For example, how about automating module tests against different versions of Node to determine whether it's in a good running status now for the current and prior interpreter versions, on the platforms it can be run on? [1] How about a prior version, in case you're trying to figure out if the version you're on has a known problem on the platform combo you're running on? [2] Or perhaps you want to know what the documentation and module structure looked like for a module a long time ago, like20 published versions and over a decade ago, because sometimes you run across old code? [3] Or as an author, the ability to upload a version, even for testing, and getting an automated report a couple days later about how well it runs on that entire version/architecture matrix with any problems you might want to look into? In case you didn't notice the trend, I'm talking about CPAN here, which has been in existence for over two decades, and many of the features I've noted have been around for at least half that time. All in and for a language that most JS devs probably think isn't in use anymore, and on encountering a professional Perl developer would probably think they just encountered a unicorn or dinosaur. Sure, NPM isn't all that bad compared to some of the examples that were put forth, but the problem is that those examples are a limited subset of what exists. Given the current popularity of JS and the massive corporate interest and sponsership, I frankly find the current situation somewhat disgusting. The only thing keeping JS from having an amazing module ecosystem is ambition. Sure, NPM might be a sound, well maintained project (points I think are debatable), but it could be so much more, and that's what we should be talking about, not almost annual fuckups[4] they seem content with dealing with. 1: http://matrix.cpantesters.org/?dist=DBIx-Class+0.082841 http://matrix.cpantesters.org/?dist=DBIx-Class+0.082841 2: http://matrix.cpantesters.org/?dist=DBIx-Class+0.08271 http://matrix.cpantesters.org/?dist=DBIx-Class+0.08271 3: https://metacpan.org/pod/release/MSTROUT/DBIx-Class-0.08000/lib/DBIx/Class.pm https://metacpan.org/pod/release/MSTROUT/DBIx-Class-0.08000/... 4: https://hn.algolia.com/?query=npm&sort=byPopularity&prefix=false&dateRange=all&type=story https://hn.algolia.com/?query=npm&sort=byPopularity&prefix=f...
    - allover 8y ago
      > Sure, NPM isn't all that bad compared to some of the examples that were put forth, but the problem is that those examples are a limited subset of what exists. That was all I was responding to. I definitely learned some cool stuff from your comment, and appreciate that, but my point was simply that the all the drive-by FUD that npm gets on HN is unwarranted. > I frankly find the current situation somewhat disgusting. This feels so hyperbolic though. The things you mention are cool 'nice-to-haves', to say not having them is 'disgusting' is a huge stretch in my opinion.
      - kbenson 8y ago
        > This feels so hyperbolic though. The things you mention are cool 'nice-to-haves' What I find somewhat disgusting is the massive amount of mistakes they've made over the years, and the time they've had to take to fix them, that could have been mitigated or entirely avoided by surveying best practices from other package management systems that have gone through the same pains. 2018-05-28 - ERR! 418 I'm a teapot (this is not a joke) https://github.com/npm/npm/issues/20791 https://news.ycombinator.com/item?id=17175960 2018-02-21 - Critical Linux filesystem permissions are being changed by latest version https://github.com/npm/npm/issues/19883 https://news.ycombinator.com/item?id=16435305 2017-08-01 - Typosquatting package names https://twitter.com/o_cee/status/892306836199800836 https://news.ycombinator.com/item?id=14905675 (a little obtuse, but moderated package namespaces with trusted maintainers can mitigate this, and spread load from levenshtein distance checks.) 2017-11-03 - Visual Studio Code 1.7 overloaded npmjs.org, release reverted https://news.ycombinator.com/item?id=12860806 (10% increase in NPM load, specifically to 404 pages, causes NPM to fall over due to naive 404 handling and apparently, poor ability to scale. Good thing they caught it at 10% instead of the 200% it would have reached...). 2016-03-29 - changes to npm’s unpublish policy https://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy https://news.ycombinator.com/item?id=11382885 2014-02-28 - npm’s Self-Signed Certificate is No More https://blog.npmjs.org/post/78085451721/npms-self-signed-certificate-is-no-more https://news.ycombinator.com/item?id=7320833 2012-03-08 - npm (Node's package manager) leaks all user password hashes and salts https://gist.github.com/jashkenas/2001456 https://news.ycombinator.com/item?id=3679996 That's just from the first page of the HN search I included previously (link 4), I doubt it's really exhaustive. Now, to me, that list of problems would be bad enough, but NPM is actually run by a for-profit company, and gates certain features behind paid accounts. So what we have is a business, catering to what is likely the largest current group of developers that exist, for a language with corporate backing by multiple very large companies, providing vital infrastructure support for that language and those users, and getting their asses handed to them in comparison to some others who are manned by people volunteering spare time, skill and equipment. I mean, I would cut them a little slack if they seemed to have plans for making stuff better and a roadmap and it was just a matter of time, effort and resources they were lacking, but it seems to continuously be a case of them waiting until the shit hits the fan and they're forced to first take a look and see how to fix this new problem they've never envisioned, and then figure out their solution. Sure, it can sound hyperbolic initially, but I think that's just because people haven't really stopped to take stock of what's really going on here, and how it's not really getting better in any useful way. In the midst of emergency fixes is not how you should plan your new features. :/
innocentoldguy 8y ago
I've worked with Maven, Ruby's gems, Python's pip, whatever Go's non-existent package management is called, and Node, via npm and yarn. I'd have to say my favorite tooling and package management is found in Elixir's mix utility though. I don't mind the others. They are all decent enough, but I think the Elixir team really nailed it with mix.
kenhwang 8y ago
Recently, when I use npm, it mostly just works. There's still the occasional node/npm version mix and match to get certain libraries to work and accidental sudo; the former might just be the poor quality of the ecosystem, and the latter is almost just user error. I'd put it par with rubygems, ahead of pip, gradle, maven, a little bit behind mix, and far behind cargo. Not a bad spot to be by any means.
- saurik 8y ago
  > far behind cargo For the purposes of this discussion, it is useful to note that cargo was written by Yehuda Katz (wycats), who had previously written Bundler, and so actually had some concept of what mistakes he had made before and experience specifically in this area, in order to apparently (I haven't used it yet, but I have heard lots of good things) finally have built something truly great.
  - jergason 8y ago
    He also helped write yarn, an alternative client to the official npm one.
donatj 8y ago
- https://research.swtch.com/vgo https://research.swtch.com/vgo - https://github.com/golang/dep https://github.com/golang/dep
CSMastermind 8y ago
npm is the worst software I use daily. * The maintainers have pushed several breaking updates by mistake (I'm a teapot recently). * There have been a few cascading failures due to the ecosystem (leftpad). * node-gyp (alluded to in the talk) break cryptically on install in different operating system/package combinations. It also obscures the actual package contents. * The lack of package signatures and things like namespace squatting significantly hurt the overall security of npm. And let's not forget how terrible things were pre-yarn with the nested folder structure of node_modules and no lock file. Compare that to NuGet where I've literally never had any of these problems.
- xab9 8y ago
  I can't argue with you, but "most of the time" it works. Not that I have a choice (unless I stop being a frontend developer), but the time we spend with node/npm debugging is not critical in the timesheet/log.
  - pjmlp 8y ago
    There is a choice, I do native frontend.
    - xab9 8y ago
      What tech are you using? Guess not react native then :)
      - pjmlp 8y ago
        Windows Forms, WPF, UWP, Android, Qt, depending on the project.
- darzu 8y ago
  Here's one thing Node and npm are great at and NuGet fails at completely: local development of two packages. With npm, I can use "npm link" to redirect a package reference to a local folder. With NuGet, the best you an do is edit the .csproj and change the nuget reference to a project reference (if you can find the original source code). This makes simple step-through debugging across package boundaries a chore every time, whereas a source-based package system doesn't have this issue.
stickfigure 8y ago
I've worked with all of these as well, and npm is probably my least favorite. Above all else, I expect my build system to do ONE THING: Exactly reproduce a build at a later date Part of it is technological (npm didn't have package-lock.json until very recently), part of it is organizational (the npm repository is surprisingly fluid), and part of it is cultural (the JS community likes zillions of tiny constantly-changing libraries). The net result is that I cannot walk away from a JS build for three weeks without something breaking. It breaks all the time. UGH.

by tnolet 8y ago

jonny_eh 8y ago

You'll find much harsher critics of Node/NPM in these parts! I thought Ryan did a great job of explaining his regrets without giving the impression that Node was a "mistake", is "inferior", or anything so drastic.

allover 8y ago
> You'll find much harsher critics of Node/NPM in these parts! They're ill-informed. GPP is correct that, for example pip is fundamentally inferior to npm [1], and those that insist on throwing shade at npm on HN should be corrected. They're wrong, and insulting a sound, well maintained project, without basis. [1] https://github.com/pypa/pip/issues/988 https://github.com/pypa/pip/issues/988
- kbenson 8y ago
  > those that insist on throwing shade at npm on HN should be corrected. Preferrably by giving them better ammunition, since I do see NPM as substandard in quite a few ways, which is inexcusable when there do exist examples to learn from (whether it be a positive or negative influence). First, it helps to clarify whether we are talking about npm the client or NPM the repository and ecosystem. Client issues are generally easily resolved, just use a different client. For npm, this could be yarn. For cpan, this could be cpanm, or cpanplus, etc. If it's indeed the repository we are talking about, there are some obvious things that could be done to greatly improve it the NPM module ecosystem. For example, how about automating module tests against different versions of Node to determine whether it's in a good running status now for the current and prior interpreter versions, on the platforms it can be run on? [1] How about a prior version, in case you're trying to figure out if the version you're on has a known problem on the platform combo you're running on? [2] Or perhaps you want to know what the documentation and module structure looked like for a module a long time ago, like20 published versions and over a decade ago, because sometimes you run across old code? [3] Or as an author, the ability to upload a version, even for testing, and getting an automated report a couple days later about how well it runs on that entire version/architecture matrix with any problems you might want to look into? In case you didn't notice the trend, I'm talking about CPAN here, which has been in existence for over two decades, and many of the features I've noted have been around for at least half that time. All in and for a language that most JS devs probably think isn't in use anymore, and on encountering a professional Perl developer would probably think they just encountered a unicorn or dinosaur. Sure, NPM isn't all that bad compared to some of the examples that were put forth, but the problem is that those examples are a limited subset of what exists. Given the current popularity of JS and the massive corporate interest and sponsership, I frankly find the current situation somewhat disgusting. The only thing keeping JS from having an amazing module ecosystem is ambition. Sure, NPM might be a sound, well maintained project (points I think are debatable), but it could be so much more, and that's what we should be talking about, not almost annual fuckups[4] they seem content with dealing with. 1: http://matrix.cpantesters.org/?dist=DBIx-Class+0.082841 http://matrix.cpantesters.org/?dist=DBIx-Class+0.082841 2: http://matrix.cpantesters.org/?dist=DBIx-Class+0.08271 http://matrix.cpantesters.org/?dist=DBIx-Class+0.08271 3: https://metacpan.org/pod/release/MSTROUT/DBIx-Class-0.08000/lib/DBIx/Class.pm https://metacpan.org/pod/release/MSTROUT/DBIx-Class-0.08000/... 4: https://hn.algolia.com/?query=npm&sort=byPopularity&prefix=false&dateRange=all&type=story https://hn.algolia.com/?query=npm&sort=byPopularity&prefix=f...
  - allover 8y ago
    > Sure, NPM isn't all that bad compared to some of the examples that were put forth, but the problem is that those examples are a limited subset of what exists. That was all I was responding to. I definitely learned some cool stuff from your comment, and appreciate that, but my point was simply that the all the drive-by FUD that npm gets on HN is unwarranted. > I frankly find the current situation somewhat disgusting. This feels so hyperbolic though. The things you mention are cool 'nice-to-haves', to say not having them is 'disgusting' is a huge stretch in my opinion.
    - kbenson 8y ago
      > This feels so hyperbolic though. The things you mention are cool 'nice-to-haves' What I find somewhat disgusting is the massive amount of mistakes they've made over the years, and the time they've had to take to fix them, that could have been mitigated or entirely avoided by surveying best practices from other package management systems that have gone through the same pains. 2018-05-28 - ERR! 418 I'm a teapot (this is not a joke) https://github.com/npm/npm/issues/20791 https://news.ycombinator.com/item?id=17175960 2018-02-21 - Critical Linux filesystem permissions are being changed by latest version https://github.com/npm/npm/issues/19883 https://news.ycombinator.com/item?id=16435305 2017-08-01 - Typosquatting package names https://twitter.com/o_cee/status/892306836199800836 https://news.ycombinator.com/item?id=14905675 (a little obtuse, but moderated package namespaces with trusted maintainers can mitigate this, and spread load from levenshtein distance checks.) 2017-11-03 - Visual Studio Code 1.7 overloaded npmjs.org, release reverted https://news.ycombinator.com/item?id=12860806 (10% increase in NPM load, specifically to 404 pages, causes NPM to fall over due to naive 404 handling and apparently, poor ability to scale. Good thing they caught it at 10% instead of the 200% it would have reached...). 2016-03-29 - changes to npm’s unpublish policy https://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy https://news.ycombinator.com/item?id=11382885 2014-02-28 - npm’s Self-Signed Certificate is No More https://blog.npmjs.org/post/78085451721/npms-self-signed-certificate-is-no-more https://news.ycombinator.com/item?id=7320833 2012-03-08 - npm (Node's package manager) leaks all user password hashes and salts https://gist.github.com/jashkenas/2001456 https://news.ycombinator.com/item?id=3679996 That's just from the first page of the HN search I included previously (link 4), I doubt it's really exhaustive. Now, to me, that list of problems would be bad enough, but NPM is actually run by a for-profit company, and gates certain features behind paid accounts. So what we have is a business, catering to what is likely the largest current group of developers that exist, for a language with corporate backing by multiple very large companies, providing vital infrastructure support for that language and those users, and getting their asses handed to them in comparison to some others who are manned by people volunteering spare time, skill and equipment. I mean, I would cut them a little slack if they seemed to have plans for making stuff better and a roadmap and it was just a matter of time, effort and resources they were lacking, but it seems to continuously be a case of them waiting until the shit hits the fan and they're forced to first take a look and see how to fix this new problem they've never envisioned, and then figure out their solution. Sure, it can sound hyperbolic initially, but I think that's just because people haven't really stopped to take stock of what's really going on here, and how it's not really getting better in any useful way. In the midst of emergency fixes is not how you should plan your new features. :/

innocentoldguy 8y ago

I've worked with Maven, Ruby's gems, Python's pip, whatever Go's non-existent package management is called, and Node, via npm and yarn. I'd have to say my favorite tooling and package management is found in Elixir's mix utility though. I don't mind the others. They are all decent enough, but I think the Elixir team really nailed it with mix.

kenhwang 8y ago

Recently, when I use npm, it mostly just works. There's still the occasional node/npm version mix and match to get certain libraries to work and accidental sudo; the former might just be the poor quality of the ecosystem, and the latter is almost just user error. I'd put it par with rubygems, ahead of pip, gradle, maven, a little bit behind mix, and far behind cargo. Not a bad spot to be by any means.

saurik 8y ago
> far behind cargo For the purposes of this discussion, it is useful to note that cargo was written by Yehuda Katz (wycats), who had previously written Bundler, and so actually had some concept of what mistakes he had made before and experience specifically in this area, in order to apparently (I haven't used it yet, but I have heard lots of good things) finally have built something truly great.
- jergason 8y ago
  He also helped write yarn, an alternative client to the official npm one.

donatj 8y ago

- https://research.swtch.com/vgo https://research.swtch.com/vgo - https://github.com/golang/dep https://github.com/golang/dep

CSMastermind 8y ago

npm is the worst software I use daily. * The maintainers have pushed several breaking updates by mistake (I'm a teapot recently). * There have been a few cascading failures due to the ecosystem (leftpad). * node-gyp (alluded to in the talk) break cryptically on install in different operating system/package combinations. It also obscures the actual package contents. * The lack of package signatures and things like namespace squatting significantly hurt the overall security of npm. And let's not forget how terrible things were pre-yarn with the nested folder structure of node_modules and no lock file. Compare that to NuGet where I've literally never had any of these problems.

xab9 8y ago
I can't argue with you, but "most of the time" it works. Not that I have a choice (unless I stop being a frontend developer), but the time we spend with node/npm debugging is not critical in the timesheet/log.
- pjmlp 8y ago
  There is a choice, I do native frontend.
  - xab9 8y ago
    What tech are you using? Guess not react native then :)
    - pjmlp 8y ago
      Windows Forms, WPF, UWP, Android, Qt, depending on the project.
darzu 8y ago
Here's one thing Node and npm are great at and NuGet fails at completely: local development of two packages. With npm, I can use "npm link" to redirect a package reference to a local folder. With NuGet, the best you an do is edit the .csproj and change the nuget reference to a project reference (if you can find the original source code). This makes simple step-through debugging across package boundaries a chore every time, whereas a source-based package system doesn't have this issue.

stickfigure 8y ago

I've worked with all of these as well, and npm is probably my least favorite. Above all else, I expect my build system to do ONE THING: Exactly reproduce a build at a later date Part of it is technological (npm didn't have package-lock.json until very recently), part of it is organizational (the npm repository is surprisingly fluid), and part of it is cultural (the JS community likes zillions of tiny constantly-changing libraries). The net result is that I cannot walk away from a JS build for three weeks without something breaking. It breaks all the time. UGH.