4 ms·
i would pay for a service that runs an NPM mirror of a "last known good" version of packages to avoid this kind of thing. just keep all my dependencies a few w
by notatoad 5y ago
i would pay for a service that runs an NPM mirror of a "last known good" version of packages to avoid this kind of thing. just keep all my dependencies a few weeks behind NPM to give things like this a chance to get caught, and let me continue blindly updating.
every time something like this happens, the reaction in the comments is the same: well you should test your dependencies. and yeah, i do that before release, but running an npm update on my dev branch and finding one of my dependencies has broken something is a bunch of work i could do without, and seems like work that is being duplicated by a ton of developers.
- cerved 5y agoYou're using a VCS I presume? Why not just rollback?
- noobermin 5y agoThe replies here (and on twitter) really are making me realize a lot of the hurt that will possibly stem from marak's actions really were ripe to happen given the sheer number of javascript developers who don't understand at all what they're doing. IT people for some reason tend not to be great at introspection which tells me this won't be fixed because this is more than just one asshole dude, this is a systemic issue with js and web development as a whole. This sort of thing would be really hard to accomplish in Linux for example because of the mentality they adopted early on when Linus had his first burn out moment, but the fact that even after leftpad nothing has changed really shows how systemically broken web dev is.
- samhh 5y agoAnecdotal but everywhere I've worked on JS codebases has used lockfiles. It might be this isn't affecting that many but those it is affecting are loud.
- umvi 5y agoRollback what? You can't rollback someone else's dependencies.
- cerved 5y agoYour source code obviously
- kristjansson 5y agoBut you can roll back your dependencies until your entire dependency graph avoids a bad version.
- umvi 5y agoYeah but in this case you might not be directly dependent on colors. You might be dependent on http-server, which is in turn dependent on colors. You can only roll back http-server, and unless http-server rolls back colors, you are stuck.
- kristjansson 5y agoSo set it in overrides? Blacklist it in your private mirror? It’s your project, your environment, and your computer, you’re never stuck.
- umvi 5y agoOh I agree, nobody is stuck. I'm just pointing out that, sure, there are messy workarounds, but in this case it is not as simple as "rollback".
- notatoad 5y agoyou mean roll back package-json.lock or package.json? yeah, but thats not really what i want. maybe my process is crazy here, but this is how i update dependencies: on a somewhat regular basis, as time allows, i run npm update to bring all my dependencies to the lastest version. then i test (including thorough manual testing / qa), commit, and release with updated dependencies. if some update is broken and i don't have time to fix it then yeah, i can roll back. but the point is to be on relatively up-to-date version of as much as possible, so if something is broken then it turns into a game of trying to figure out which library it was that broke things. i don't want to just not update any dependencies because something is broken.
- cerved 5y agoI'm confused. You're looking for a way to go back to the last good version. By your methodology wouldn't that be before you last updated? Or are you looking for a curated service? A reasonable maintainer semvers their packages. You shouldn't update to the latest version if you want to minimize the likelihood of issues. That's what stable releases are for