What NPM should do to stop a new colors attack
Attack is hyperbole. This wasn&#x27;t an <i>attack</i>. Nothing was <i>attacked</i>. This verbiage has got to stop being used around this. A maintainer of popular packages got fed up with being a maintainer - rightly or wrongly - and decided that they were going to alter their code - publicy no less (a far more dubious move would have been to make these changes in private and release that to npm, without pushing it to github also, in my mind) - and that means this code was working as intended by the project &#x2F; package maintainer.<p>It was not injecting harmful code onto the machine, it was not an &quot;attack&quot; on anything, in any real sense. I feel all the media is doing so far is raking the maintainer over a fire, instead of asking the question of <i>how did we get here in the first place? Why would a maintainer feel they need to take actions like this? What are they trying to achieve?</i><p>Instead of talking about the role of maintainers, consumers, and what to do about the state of open source software and its longevity, we are instead using this moment to go after the maintainer as if they were doing the equivalent of using their npm packages to inject actual malicious, harmful code on the consumer machines, like a cryptominer.<p>I know it inconveniences everyone, sure, and would I have done this if they were my packages? No, I&#x27;d go through a normal deprecation process of announcing its deprecation, archiving the repository, and plainly stating that the package is no longer maintained.  With that said, <i>consumers can always choose a different library.</i><p>This wasn&#x27;t malicious, or an attack. It was an update to the package working as the maintainer of the project intended. If lodash issued a breaking change, would that be considered an &quot;attack&quot;? They even followed semver, by bumping the packages to their next major version.<p>I think this event also served to expose how little organizations have around testing for breaking changes in their dependencies, which may be adding fuel to the issue.<p>EDIT: this is a plea for more nuance in the conversation. I think there has been an unreasonable amount of haste in passing judgement in this situation, that, after doing even just a little bit of background research, seems to suggest there is more moving parts than meets the surface.