3 ms·

Could you please explain a little more. I can use such practice in my dev workflow.

• hu3 2y ago
  Sure. They don't include "node_modules" directory in their .gitignore file. So any third party code changes end up in git commits and are easily visible and reviweable. So running npm update/upgrade includes the code that changed in the dependencies in the commit.
  • MortyWaves 2y ago
    Surely there has to be better ways of “vendoring” (including hosting your own package repository that doesn’t automatically pull new versions) than adding thousands or maybe tens of thousands of files to the git repo?
    • compootr 2y ago
      if it's dumb and it works it isn't dumb! another rather simple solution is a git mirror of each package, then point npm to a git url
    • xdennis 2y ago
      If my podcast memory serves, that's how Isaac (the NPM guy) said it was intended. You would `npm install` and then `git commit`. That's why npm didn't have a lock file back then. Git was the lock file.
    • guappa 2y ago
      On debian I do debdiff to see the differences between two source packages.
  • VPenkov 2y ago
    This is an option but that makes it easier to conceal malicious code within node_modules as an internal threat actor or make super sure there's a culture of actually reviewing those changes. In cases like that it helps to do npm install on the CI and make sure you end up with identical code. Decent trade-off.
• robszumski 2y ago
  this is an area that is top of mind for me right now. you don't have to vendor your deps to get a detailed report of what changed, and bonus, how your app calls into it. just wrote about it: https://edgebit.io/blog/code-diff-reachability/ https://edgebit.io/blog/code-diff-reachability/