Dude he addressed that in the next few lines:

> There are times where this doesn't work; updating TypeScript may require us to update some code to fix errors that the new version of TypeScript is now detecting. In that case we have the ability to override the rule. As with anything in software engineering, most "rules" are guidelines, and we're able to side-step them when required.

Ah, I glossed over that. But that just makes me more confused, not less. On a long lived project most changes to node_modules will require code changes... just not sure what the point is.

If your libraries have breaking changes on every update, sure. Most of the libs I use haven’t had one in decades, but I don’t write js so maybe my experiences aren’t that relevant.

You can have multiple commits in a PR

Yes, but a lot of people prefer to have every commit in master in a buildable state. Otherwise things like git bisect become a lot more tedious.

> have every commit in master

Yes, but a PR commit is not in master.

I see you, little squasher :)

But then you lose the benefit. Hiding node_modules during code review is the easy part.

Some teams force all pull requests to be squashed to a single commit.