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:

  1. Git diff between 2 commits to get the files changed
  2. Compile a list of packages that are directly affected by the files changed
  3. 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:

  1. 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.
  2. For Monorepos using Lerna, for example, you can safely run a standard script and know that every package is following that structure.
  3. It’s easy to create a new package, either…

Flavio Carvalho

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store