[strogonoff]

> making the lockfiles more complicated?

Poor phrasing; I meant the attacks. Now you don’t just have a lockfile you need to sneakily modify, and the diff grows.

As to your second point, yes. It’s really a different feeling when you add one more package and suddenly have 215 new files to check in!

[KajMagnus]

> suddenly have 215 new files to check in!

How big is your repo, if I may ask?

Personally I store vendored dependencies in a submodule, where I can squash history, if it grows too large.

[strogonoff]

> How big is your repo

It’s a subjective question, but in one of the zero-installs projects I definitely remember that when I added a couple of particular GUI libraries there suddenly a very, very long list of new files to track, since those maintainers to keep things decoupled. I wouldn’t stop using that library at that point (there were deadlines), but I would definitely try to find something lighter or more batteries-included next time.

There can be a tiny project with just one dependency that happens to have an overgrown, massive graph of further transitive dependencies (a very unpleasant scenario which I would recommend to avoid).

With zero installs turned on, such a codebase could indeed qualify as “big repo”, which I think would reflect well its true nature.

Without zero installs it could be tiny but with a long long lockfile that nobody really checks when committing changes.

> Personally I store vendored dependencies in a submodule

I don’t like the added mental overhead of submodules, and so prefer to avoid them when possible, which I guess is a subjective preference.

Since this is, coneptually speaking, the matter of package management more so than it is the matter of version control in genetal, I prefer to rely on package manager layer to handle this. I can see how your approach could make sense, but honestly I would be more anxious about forgetting something when keeping vendored dependencies up-to-date in that scenario.

Your approach could be better in a sense that you can spot-check not just the list of changed packages, but also the actual code (since you presumably vendor them as is, while Yarn checks in compressed .tgz files). Not sure whether that justifies the added friction.