If you don't test library upgrades before they are applied somewhere serious the malicious party is you.
If you don't have a contract with the developer maintaining a library you can't expect them to keep it maintained, backwards compatible &c. So if you just grab a MIT licensed lib, fork it and maintain your own repo, merging in whatever the upstream adds that you've reviewed and tested.
This is common sense, and not a fault on Marak's part.
Problem is that package dependencies are specified as boundaries. You write a library, and in this library you specify
"peerDependencies": {
"colors": "^1.3.0"
}
Then, when using this new library in one of your applications, NPM finds the most optimal version of this "colors" package (which for example is "1.4.0") which in this case contains the corrupted code. So to be perfect, each package should publish another version excluding this version of colors:
"peerDependencies": {
"colors": "^1.3.0 <1.4.0"
}
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If you don't test library upgrades before they are applied somewhere serious the malicious party is you.
If you don't have a contract with the developer maintaining a library you can't expect them to keep it maintained, backwards compatible &c. So if you just grab a MIT licensed lib, fork it and maintain your own repo, merging in whatever the upstream adds that you've reviewed and tested.
This is common sense, and not a fault on Marak's part.
Problem is that package dependencies are specified as boundaries. You write a library, and in this library you specify
Then, when using this new library in one of your applications, NPM finds the most optimal version of this "colors" package (which for example is "1.4.0") which in this case contains the corrupted code. So to be perfect, each package should publish another version excluding this version of colors: