5 ms·

That would be a clear violation of the npm Unpublish Policy[0]. If all it takes is some spam and pissing people off to walk away from principles, they never mea

by 3np 2y ago

That would be a clear violation of the npm Unpublish Policy[0]. If all it takes is some spam and pissing people off to walk away from principles, they never meant anything. A proper response needs to not break expectations like this. [0]: https://docs.npmjs.com/policies/unpublish https://docs.npmjs.com/policies/unpublish

bigDinosaur 2y ago
The entire NPM ecosystem is a garbage fire. Who cares about whatever 'principles' it supposedly has? Other than avoiding malware I can't think of something I care about less than whatever principles NPM / JS developers in general have because they've mostly been bad so far. I wouldn't be surprised if principles in this case leave us with thousands of spam packages degrading the node ecosystem forever. It'd be exactly what I expect. So I guess I should thank the principle of consistency.
- _heimdall 2y ago
  Its not about principles in some abstract sense though, its terms if use. Package authors need to know what the rules of the road are when dedicating time to publishing to npm, and package users need to know how much they can rely on the packages they depend on still being there tomorrow. It'd be one thing if npm added audit warnings along the lines of "3 dependencies are likely spam." It'd be a totally different story for npm to remove them automatically based on a toolset used, in the GP example.
- lolinder 2y ago
  I know it's a meme on HN to rant about the terrible JavaScript ecosystem and how bad JS developers are, but I would ask that if you're going to do it you be specific about what you mean instead of just generally accusing it of being "bad". It's not even that I disagree, it's that it's a conversation killer. "The JS ecosystem is bad" has no response someone could make besides "no it's not", which is boring. "The JS ecosystem encourages using a million tiny unmaintained packages and that is bad" is a much more interesting statement that can spark a useful discussion.
  - sushibowl 2y ago
    > The JS ecosystem encourages using a million tiny unmaintained packages and that is bad continuing on this, I wonder if this is a cultural thing or if there are actual technical choices made in NPM that play a role. Could NPM change something in their package management to change this? Should they?
    - brynb 2y ago
      it's language-cultural. to "publish a package" in Go simply means having a public git repository. and yet, nobody who writes Go imports packages. it's well-understood that if you can't write something like leftpad (or many other JS packages) yourself in your own codebase in a few lines, you're an absolute nonce. Javascript developers on the other hand tend to skew towards the juniors in our broader ecosystem, and they seek easy and quick prestige, which leads to "star farming"/"download farming"
      - lupire 2y ago
        So no one uses all those Go libraries on GitHub? Hmmm except pedophiles? What is wrong with you?
        brynb 2y ago
        ... _what_? i don't think you parsed my comment correctly at all to address the part of your comment that doesn't make my head spin: only very occasionally do i see senior Go developers import 3rd party libraries. i'm just speaking from my experience
  - marginalia_nu 2y ago
    We can empirically observe that NPM-sphere is relatively alone among software ecosystems to have this particular problem. This is an indication that the problem is either with some facet of NPM itself, javascript the language or js programmers, as that is what distinguishes the ecosystem from e.g. Maven or Pip that do not suffer from the same problems, at least not to the same extent. However, going from this observation to isolating causal factors is a lot harder, and randomly guessing isn't very likely to hit the mark.
huimang 2y ago
Do principles matter if a registry becomes seen as spam or a security risk due to refusing to take action?
wesselbindt 2y ago
Principles are a means to an end, not an end in themselves. The end here (presumably) is a healthy ecosystem, an end which this principle arguably harms more than it helps. Rigid and unthinking adherence to principles is dogmatic, and dogma has no place in engineering.
- lolinder 2y ago
  > The end here (presumably) is a healthy ecosystem More specifically, the end here is a package manager that doesn't randomly start break your builds because a dependency you need can just vanish from the main servers or lose files you expected to be there. That may or may not contribute to a healthy ecosystem, but it definitely contributes to widespread usage of npm.
  - pixl97 2y ago
    No, that is but one condition of the end, but not the whole of the end. A system is all the parts it requires to continue to exist. Widespread usage of NPM will collapse if everything on it is hot dangerous garbage that infects your CI-CD/dev box with something when you type a wrong character. There are multiple dimensions to trust. Is the package I'm using going to disappear is one. Is the package I'm using a virus is another. Is the entire NPM ecosystem going to collapse under the weight of controlled growth and hosting costs leaving me with nothing is yet another. You need to back up and look at the whole elephant.
  - brynb 2y ago
    if you've been duped into importing a package which has been broadly deemed as spam (but you're not looped into the public conversation about that fact enough to realize it), wouldn't "breaking the build" be a good way to get you to realize your folly and avoid the trap?
rk06 2y ago
Pragmatism trumps principles. In this case, it is better to unpublish these packages, than turn npm registry into a bigger garbage
edflsafoiewq 2y ago
How about banning it going forward instead?
dotancohen 2y ago
Never let your principles get in the way of doing what is right. - Isaac Asimov
yamumzahoe 2y ago
[flagged]
- barryrandall 2y ago
  Leave the packages online, but remove them from indexes and require --force to install them.
  - yamumzahoe 2y ago
    [flagged]
alright2565 2y ago
No, it isn't? The unpublish document describes the options that users of NPM have to remove packages themselves. It was created after some situation where someone unpublished an important package. A whole different set of terms governs which packages NPM can remove. This definitely includes these packages, either as "abusive" or "name squatting" Not only that, but NPM's TOS makes it very clear that you have no recourse if they decide to remove your package for any reason.
- 3np 2y ago
  > Registry data is immutable, meaning once published, a package cannot change. We do this for reasons of security and stability of the users who depend on those packages. So if you've ever published a package called "bob" at version 1.1.0, no other package can ever be published with that name at that version. This is true even if that package is unpublished. This statement makes assertions and sets expectations for both publishers and users. It would be senseless if npmjs would start arbitrarily "taking down" packages on their own discretion simply because they include a tea.yaml file (as proposed in the comment I replied to).

by 3np 2y ago

bigDinosaur 2y ago

The entire NPM ecosystem is a garbage fire. Who cares about whatever 'principles' it supposedly has? Other than avoiding malware I can't think of something I care about less than whatever principles NPM / JS developers in general have because they've mostly been bad so far. I wouldn't be surprised if principles in this case leave us with thousands of spam packages degrading the node ecosystem forever. It'd be exactly what I expect. So I guess I should thank the principle of consistency.

_heimdall 2y ago
Its not about principles in some abstract sense though, its terms if use. Package authors need to know what the rules of the road are when dedicating time to publishing to npm, and package users need to know how much they can rely on the packages they depend on still being there tomorrow. It'd be one thing if npm added audit warnings along the lines of "3 dependencies are likely spam." It'd be a totally different story for npm to remove them automatically based on a toolset used, in the GP example.
lolinder 2y ago
I know it's a meme on HN to rant about the terrible JavaScript ecosystem and how bad JS developers are, but I would ask that if you're going to do it you be specific about what you mean instead of just generally accusing it of being "bad". It's not even that I disagree, it's that it's a conversation killer. "The JS ecosystem is bad" has no response someone could make besides "no it's not", which is boring. "The JS ecosystem encourages using a million tiny unmaintained packages and that is bad" is a much more interesting statement that can spark a useful discussion.
- sushibowl 2y ago
  > The JS ecosystem encourages using a million tiny unmaintained packages and that is bad continuing on this, I wonder if this is a cultural thing or if there are actual technical choices made in NPM that play a role. Could NPM change something in their package management to change this? Should they?
  - brynb 2y ago
    it's language-cultural. to "publish a package" in Go simply means having a public git repository. and yet, nobody who writes Go imports packages. it's well-understood that if you can't write something like leftpad (or many other JS packages) yourself in your own codebase in a few lines, you're an absolute nonce. Javascript developers on the other hand tend to skew towards the juniors in our broader ecosystem, and they seek easy and quick prestige, which leads to "star farming"/"download farming"
    - lupire 2y ago
      So no one uses all those Go libraries on GitHub? Hmmm except pedophiles? What is wrong with you?
      - brynb 2y ago
        ... _what_? i don't think you parsed my comment correctly at all to address the part of your comment that doesn't make my head spin: only very occasionally do i see senior Go developers import 3rd party libraries. i'm just speaking from my experience
- marginalia_nu 2y ago
  We can empirically observe that NPM-sphere is relatively alone among software ecosystems to have this particular problem. This is an indication that the problem is either with some facet of NPM itself, javascript the language or js programmers, as that is what distinguishes the ecosystem from e.g. Maven or Pip that do not suffer from the same problems, at least not to the same extent. However, going from this observation to isolating causal factors is a lot harder, and randomly guessing isn't very likely to hit the mark.

huimang 2y ago

Do principles matter if a registry becomes seen as spam or a security risk due to refusing to take action?

wesselbindt 2y ago

Principles are a means to an end, not an end in themselves. The end here (presumably) is a healthy ecosystem, an end which this principle arguably harms more than it helps. Rigid and unthinking adherence to principles is dogmatic, and dogma has no place in engineering.

lolinder 2y ago
> The end here (presumably) is a healthy ecosystem More specifically, the end here is a package manager that doesn't randomly start break your builds because a dependency you need can just vanish from the main servers or lose files you expected to be there. That may or may not contribute to a healthy ecosystem, but it definitely contributes to widespread usage of npm.
- pixl97 2y ago
  No, that is but one condition of the end, but not the whole of the end. A system is all the parts it requires to continue to exist. Widespread usage of NPM will collapse if everything on it is hot dangerous garbage that infects your CI-CD/dev box with something when you type a wrong character. There are multiple dimensions to trust. Is the package I'm using going to disappear is one. Is the package I'm using a virus is another. Is the entire NPM ecosystem going to collapse under the weight of controlled growth and hosting costs leaving me with nothing is yet another. You need to back up and look at the whole elephant.
- brynb 2y ago
  if you've been duped into importing a package which has been broadly deemed as spam (but you're not looped into the public conversation about that fact enough to realize it), wouldn't "breaking the build" be a good way to get you to realize your folly and avoid the trap?

rk06 2y ago

Pragmatism trumps principles. In this case, it is better to unpublish these packages, than turn npm registry into a bigger garbage

edflsafoiewq 2y ago

How about banning it going forward instead?

dotancohen 2y ago

Never let your principles get in the way of doing what is right. - Isaac Asimov

yamumzahoe 2y ago

[flagged]

barryrandall 2y ago
Leave the packages online, but remove them from indexes and require --force to install them.
- yamumzahoe 2y ago
  [flagged]

alright2565 2y ago

No, it isn't? The unpublish document describes the options that users of NPM have to remove packages themselves. It was created after some situation where someone unpublished an important package. A whole different set of terms governs which packages NPM can remove. This definitely includes these packages, either as "abusive" or "name squatting" Not only that, but NPM's TOS makes it very clear that you have no recourse if they decide to remove your package for any reason.

3np 2y ago
> Registry data is immutable, meaning once published, a package cannot change. We do this for reasons of security and stability of the users who depend on those packages. So if you've ever published a package called "bob" at version 1.1.0, no other package can ever be published with that name at that version. This is true even if that package is unpublished. This statement makes assertions and sets expectations for both publishers and users. It would be senseless if npmjs would start arbitrarily "taking down" packages on their own discretion simply because they include a tea.yaml file (as proposed in the comment I replied to).