7 ms·

Imo your solution is just a band aid. The real solution is having a distribution of packages which are maintained and suppervised by a group of people. Like the

Imo your solution is just a band aid. The real solution is having a distribution of packages which are maintained and suppervised by a group of people. Like the linux distribution maintainers or the group that develops the language. Community contribuited packages should be declared "install at own risk" like in archlinux aur. All this is already solved. But people want to reinvent the wheel and ride the user generated content train.

hobofan 7y ago
That's not a "solution". That's just shifting the trust to a different (smaller) group of people.
- jonas21 7y ago
  > That's just shifting the trust to a different (smaller) group of people. Practically speaking, shifting trust from a large, anonymous group of people, to a small group of people who are known and trusted by the community is a pretty good solution.
  - krainboltgreene 7y ago
    Please list the group of people you trust to manage 1,037,274 packages.
    - layoutIfNeeded 7y ago
      (Of which 1,000,000 are slight variations of leftpad.)
    - hedora 7y ago
      I trust these people to manage software packages: https://nm.debian.org/public/people/dm_all https://nm.debian.org/public/people/dm_all They “only” manage ~18K packages, but those 18K do a lot more than NPM: https://people.debian.org/~corsac/ https://people.debian.org/~corsac/ perhaps number of packages is the wrong metric.
      - GordonS 7y ago
        A lot of those packages are going to be versions months or sometimes years behind the latest version. I'm not convinced this is a model that can work for programming libraries.
        umanwizard 7y ago
        It does work, in practice, and has for years. Every package in the Debian (or Ubuntu, or FreeBSD, etc.) package repos depends only on other packages in those repos and on the base OS. It works fine. Packages being months behind the latest version is a feature, not a bug — it means things will only be randomly changing under your feet rarely, with the exception of security fixes.
        soulofmischief 7y ago
        But it doesn't work for libraries people will be using in development. Often you are waiting for a handful of packages to introduce specific features or bug fixes and need them the moment they are available. NPM isn't user space, it's dev space. Timeliness is the maxim.
        umanwizard 7y ago
        I’m not a JS developer so maybe I’m missing something, but how do you use a library during development and not use it in production? In the C++ world, I can’t imagine a situation where you would need to depend on, for example, libjpg while developing, but not need to read JPEG files in prod/end-user-space.
        naniwaduni 7y ago
        In the C++ world, you almost certainly don't need headers in prod.
        umanwizard 7y ago
    - JustSomeNobody 7y ago
      What do you propose should be done?
    - fock 7y ago
      Tell me, why one needs packages such as this except for personal (and ultimately npm) marketing: https://github.com/sindresorhus/shebang-regex https://github.com/sindresorhus/shebang-regex - the whole thing smells
      - inimino 7y ago
        You're being downvoted because that is mean-spirited, but the reason we needed these packages is to find out what the right size of package is. We now have a lower bound.
        fock 7y ago
        I'm not sure what's mean-spirited about the simple statement that the size/complexity of the npm-eco-system arises only from personal/corporate business-decisions. But thanks for telling me anyways ;)
        inimino 7y ago
        Business decisions and marketing are not the only reasons people write open source software and you would do well to remember it.
  - hanniabu 7y ago
    In my opinion there should be different namespaces, similar to what the parent mentioned. There can still be the public namespace as there is now, but there can also be ones registered, such as google/mysql-golang. The other alternative is that it's just linked to Github/Gitlab, but then you run into potential naming collision issues.
matthewbauer 7y ago
That comes at a cost of lots of volunteer hours. I’m not sure if it would scale to NPM’s massive size.
- naniwaduni 7y ago
  npm's size is not independent of its curation strategy. This can be construed as a good or a bad thing.
  - kjksf 7y ago
    NPM's size is first and foremost dependent on the popularity of JavaScript. All other "modern" (where "modern" is "last 20 years") package managers have zero curation. Perl, Python, Ruby, Go, Rust, Dart, JavaScript. You say: "if they had curation, they would be better". I say: "if they had curation, they would have lost to a competitor that doesn't have curation". People care about having more packages much more than abstract fears of security or quality of those packages.
    - umanwizard 7y ago
      > modern Apt is about 20 years old, and the most famous apt package repos (I.e., the Ubuntu project) is much younger than that.
    - TeMPOraL 7y ago
      People care about having more packages much more than abstract fears of security or quality of those packages. At their own peril.
    - justinclift 7y ago
      > People care about having more packages much more than abstract fears of security or quality of those packages. You're partially right. Some people haven't yet learned (eg the hard way, or whatever) that quality does matter. Hopefully most of those people will learn to appreciate and demand quality over time, instead of the current anything-goes-approach. In the meantime, things like this npm package example will continue to give npm/javascript black eyes (repeatedly) and help make that happen. :)

hobofan 7y ago

That's not a "solution". That's just shifting the trust to a different (smaller) group of people.

jonas21 7y ago
> That's just shifting the trust to a different (smaller) group of people. Practically speaking, shifting trust from a large, anonymous group of people, to a small group of people who are known and trusted by the community is a pretty good solution.
- krainboltgreene 7y ago
  Please list the group of people you trust to manage 1,037,274 packages.
  - layoutIfNeeded 7y ago
    (Of which 1,000,000 are slight variations of leftpad.)
  - hedora 7y ago
    I trust these people to manage software packages: https://nm.debian.org/public/people/dm_all https://nm.debian.org/public/people/dm_all They “only” manage ~18K packages, but those 18K do a lot more than NPM: https://people.debian.org/~corsac/ https://people.debian.org/~corsac/ perhaps number of packages is the wrong metric.
    - GordonS 7y ago
      A lot of those packages are going to be versions months or sometimes years behind the latest version. I'm not convinced this is a model that can work for programming libraries.
      - umanwizard 7y ago
        It does work, in practice, and has for years. Every package in the Debian (or Ubuntu, or FreeBSD, etc.) package repos depends only on other packages in those repos and on the base OS. It works fine. Packages being months behind the latest version is a feature, not a bug — it means things will only be randomly changing under your feet rarely, with the exception of security fixes.
        soulofmischief 7y ago
        But it doesn't work for libraries people will be using in development. Often you are waiting for a handful of packages to introduce specific features or bug fixes and need them the moment they are available. NPM isn't user space, it's dev space. Timeliness is the maxim.
        umanwizard 7y ago
        I’m not a JS developer so maybe I’m missing something, but how do you use a library during development and not use it in production? In the C++ world, I can’t imagine a situation where you would need to depend on, for example, libjpg while developing, but not need to read JPEG files in prod/end-user-space.
        naniwaduni 7y ago
        In the C++ world, you almost certainly don't need headers in prod.
        umanwizard 7y ago
  - JustSomeNobody 7y ago
    What do you propose should be done?
  - fock 7y ago
    Tell me, why one needs packages such as this except for personal (and ultimately npm) marketing: https://github.com/sindresorhus/shebang-regex https://github.com/sindresorhus/shebang-regex - the whole thing smells
    - inimino 7y ago
      You're being downvoted because that is mean-spirited, but the reason we needed these packages is to find out what the right size of package is. We now have a lower bound.
      - fock 7y ago
        I'm not sure what's mean-spirited about the simple statement that the size/complexity of the npm-eco-system arises only from personal/corporate business-decisions. But thanks for telling me anyways ;)
        inimino 7y ago
        Business decisions and marketing are not the only reasons people write open source software and you would do well to remember it.
- hanniabu 7y ago
  In my opinion there should be different namespaces, similar to what the parent mentioned. There can still be the public namespace as there is now, but there can also be ones registered, such as google/mysql-golang. The other alternative is that it's just linked to Github/Gitlab, but then you run into potential naming collision issues.

matthewbauer 7y ago

That comes at a cost of lots of volunteer hours. I’m not sure if it would scale to NPM’s massive size.

naniwaduni 7y ago
npm's size is not independent of its curation strategy. This can be construed as a good or a bad thing.
- kjksf 7y ago
  NPM's size is first and foremost dependent on the popularity of JavaScript. All other "modern" (where "modern" is "last 20 years") package managers have zero curation. Perl, Python, Ruby, Go, Rust, Dart, JavaScript. You say: "if they had curation, they would be better". I say: "if they had curation, they would have lost to a competitor that doesn't have curation". People care about having more packages much more than abstract fears of security or quality of those packages.
  - umanwizard 7y ago
    > modern Apt is about 20 years old, and the most famous apt package repos (I.e., the Ubuntu project) is much younger than that.
  - TeMPOraL 7y ago
    People care about having more packages much more than abstract fears of security or quality of those packages. At their own peril.
  - justinclift 7y ago
    > People care about having more packages much more than abstract fears of security or quality of those packages. You're partially right. Some people haven't yet learned (eg the hard way, or whatever) that quality does matter. Hopefully most of those people will learn to appreciate and demand quality over time, instead of the current anything-goes-approach. In the meantime, things like this npm package example will continue to give npm/javascript black eyes (repeatedly) and help make that happen. :)