4 ms·
The arguments seem exceedingly weak here. Having a monorepo does not prevent a workflow like (1) add new function signature; (2) let all calls use the new funct
by cjfd 5y ago
The arguments seem exceedingly weak here. Having a monorepo does not prevent a workflow like (1) add new function signature; (2) let all calls use the new function signature; (3) remove old function signature. However, in some cases a multirepo makes sure you could only do it this way. If a function is called all over the place the three-step program is the only somewhat safe way to do it but if a function is called not exceedingly many times one can do the atomic refactor, which is an easier process. That one sometimes needs the three-step process and sometimes can do an atomic refactor is in no way contradictory as this article seems to claim. It depends on the size of the change and the risk involve what you would do in a particular case.
Also, a monorepo forcing trunk-based development is great. Long-living feature branches are hell. I would even say to avoid feature branches entirely and use feature switches instead whenever one can get away with it. Every branch always runs the risk of making refactoring more difficult.
- Cthulhu_ 5y agoRe: branches, I agree in principle - we've had feature branches at my current job that were open for a year, reasoning being that it impacts a lot of our application core and we cannot permit issues impacting existing customers, etc etc. But I do like short-lived (max 1 sprint) branches for my own smaller scale projects because they group changes together. I name my branches after an issue number, rebase freely on that branch, and merge with a `--no-ff` flag when I'm done. My history is a neat branch / work / merge construct. Not sure if this is just fear, but I believe trunk- and feature switch based history will end up an incoherent mess of multiple projects being worked on at the same time, commits passing through each other. I'm sure they can be filtered out, but still.
- kohlerm 5y agoIt is not the monorepo which forces trunkbased development it is the fact that you use one build for the monorepo. E.g. you can do trunk based development with multiple repos by forcing everyone to use a common build. You could also use a monorepo and still everyone does their own build consuming libraries via mechanisms such as Mavens Repositories or published npm packages