3 ms·
> We've come up with a rule that helps us here: a change that updates node_modules may not touch any other code in the codebase What? What if the dependency up
by ng12 5y ago
> We've come up with a rule that helps us here: a change that updates node_modules may not touch any other code in the codebase
What? What if the dependency upgrade requires code changes? Master is just broker until the second MR merges?
This all sounds like terrible advice.
- emteycz 5y agoYou can have multiple commits in a PR
- lf-non 5y agoYes, 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.
- xboxnolifes 5y ago> have every commit in master Yes, but a PR commit is not in master.
- clintonb 5y agoSome teams force all pull requests to be squashed to a single commit.
- deleted 5y ago[deleted]
- NavinF 5y agoDude 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.
- ng12 5y agoAh, 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.
- NavinF 5y agoIf 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.