I’ve noticed a problem when creating a bot that notifies what packages have changed on each merge request. Consider the following dependency graph:
Change package-c -> test package-{a,c}
Change package-e -> test package-{a,b,c,e}
Change package-d -> test package-{a,d}
You get the point, we only want to test the packages that are affected by a change. Getting a list of what packages changed is quite straightforward:
- Git diff between 2 commits to get the files changed
- Compile a list of packages that are directly affected by the files changed
- Compile a list of packages that are indirectly affected by the packages…
Imagine this, your team decides to split a monolith application into smaller packages, either in a monorepo or multi-repo, how do you promote standard scripts and ease of use when creating new packages?
Having a standard set of scripts for all the packages has its benefits:
- In multi-repo projects, CI/CD pipelines become very easy to create with templates; you can rely on them and use templates instead of hardcoding scripts/jobs.
- For Monorepos using Lerna, for example, you can safely run a standard script and know that every package is following that structure.
- It’s easy to create a new package, either…
