Show HN: Monorepo-hash, check if any workspace in your PNPM monorepo changed

When you're working with monorepos, there's often a lot of workspaces (packages) that end up being created.
And as your project grows, so does the number of workspaces (and so does your build times...).
If you ever worked with stuff like Next.js, you know what I'm talking about. And since every workspace requires another, you need everything to be built to test your changes.

Although there are tools that allow your scripts to run only when files have changed (ex turbo), the complete CI step cannot benefit from this. For example with turbo again, they allow you to prune just the right workspaces and dependencies when building in a Docker, but this requires copying the entire monorepo into the container so we can't benefit from Docker's layers caching.
If only there could be a way to determine if a workspace hasn't changed to not rebuild it for nothing...

Well lucky you, monorepo-hash is here to help with that !

You can install monorepo-hash globally, but it's best to add it as a dev dependency at the root of your monorepo :

Specify them in quotes, separated by commas, no spaces, and with no leading or trailing slashes.
The target name is the path to the workspace relative to the root of your monorepo, and uses forward slashes no matter your platform.

Same rules apply.

This will suppress all output except for errors. This can be useful for example in CI where only the exit code matters.

The debug mode will :

• in generate mode, output .debug-hash files which will contain the hashes of each individual file in the workspace as a JSON object
• in compare mode, read those .debug-hash files and tell you exactly which files have changed in each workspace, and what their hashes are
  This can be useful to check why the hashes appear to be different, or to debug issues with the hashes generation.

Don't forget to delete these files afterwards !

• 0 : No changes detected (or you wanted to get help)
• 1 : Changes detected in the hashes
• 2 : Error with the arguments (either --generate or --compare is missing, or both were provided)
• 3 : Unknown arguments provided
• 4 : No workspaces found, either the pnpm-workspace.yaml file is missing or the packages field is not set up correctly
• 5 : An unexpected error occurred, please open an issue with the logs

Tested in the small monorepo, with the following directory structure :

This was the main reason I created this tool, and whether it's in GitHub Actions or locally through act, it can help you to reduce drastically CI times.
Here's an example workflow that uses monorepo-hash to only build the workspaces that have changed :

Here we use the actions cache to store the .hash files, so that we can reuse them in the next runs.
This is especially useful because when you generate hashes, the action will pick them up from the latest commit and not the latest run.
For the very first run, you might need to create a workflow which will only checkout and save the .hash files in a cache for future runs.

• Only works with PNPM for now
  If you really need support for Yarn or NPM, feel free to open an issue or even submit a pull request !
• Bases the transitive dependency detection on the workspace: field in the package.json files
• If you use another Version Control System than git, we can't ignore your files correctly for the hashes generation
• Your EOL (End of Line) should be consistent across your monorepo's files and the different environments it's being used in. Since Docker containers and GitHub Actions runners are based on Linux, it's recommended to use LF as EOL.
  I recommend to set this up in your IDE and formatter config.
• Due to workspace transitive dependencies, the hashes need to be regenerated for all workspaces even when comparing only a few targets. Fortunately, this is pretty fast, see the benchmarks below.

These benchmarks have been realised on a Windows 11 laptop with an AMD Ryzen 5 5500U CPU clocked at 2.10 GHz, 16 Gb of DDR3 RAM and an old SSD (needless to say, not a very performant machine).
They have been reproduced multiple time with a warm cache (node already run once) and with all applications closed.

Small monorepo, 5k LoC : 150 ms (5 workspaces of 100 files each, files composed of 1 line of text)
Medium monorepo, 505k LoC : 2.66 s (5 workspaces of 100 folders each, with each folder containing 100 files, files composed of 10 lines of text)
Large monorepo, 505m LoC : 47.7 s (5 workspaces of 100 folders each, with each folder containing 10 files and 10 folders, and each of these folders containing 100 files, files composed of 100 lines of text)

In order to not clunk up Git, these demo repos are compressed.

Here's a quick guide for contributing to monorepo-hash :

1. Fork the repository (and star it 😉)
2. Clone your fork

3. Do your changes
4. Test your changes
   Feel free to add tests to the tests directory.

5. Commit your changes
6. Open a pull request

• Nexelec

If you use monorepo-hash in your project(s), whether you're an individual or a company, please let me know by opening an issue or a pull request, and I'll add you to this list !

I'm a young developer from France, and as I write this I'm actively seeking for a job.
If you want to support me, here's how you can do it :

• Star this repository
• Follow me on GitHub
• Donate :
  • PayPal
  • GitHub Sponsors
  • BuyMeACoffee
  • Donate on Telegram

monorepo-hash is licensed under the MIT License