It's the first release of the year, and with this release, we're landing some quality of life infrastructure and workflow improvements!
New action pipeline
When running targets, we generate a graph of actions to execute in order within the action runner. An action is one of "setup toolchain", "install dependencies", "run target", so on and so forth. Our action runner would then spawn threads for every action using the Tokio runtime. While this worked great, concurrency was entirely abstracted away from us.
To mitigate this problem, we've implemented a new system for executing actions known as the action
pipeline (or simply pipeline), which implements a dynamically scaling thread pool on top of Tokio.
This provides us with more control over concurrency, starting with the new
which restricts the number of threads (or CPU cores).
$ moon run :build --concurrency 2
Expanded hashing functionality
When we run targets in the pipeline, we hash a collection of inputs to calculate whether to continue running or to exit early. This functionality has been extremely beneficial for optimizing the pipeline, and so, we've expanded the hasher for other use cases. To start, the following 2 workflows now utilize the hasher:
- When determining to auto-install dependencies (
npm install, etc), we now hash all production, development, and peer dependencies from applicable manifests (
package.json). This has resulted in more accurate installs, as we're no longer inadvertently installing when a non-dependency field is modified in a manifest. On top of this, will still take into account lockfile modified timestamps.
- When generating the project graph, we now hash all sources, aliases, and configuration files, to determine whether to load the project graph from the local cache.
Project graph is now cached
Because of the hashing improvements above, we're now able to cache the entirety of the project graph
into local cache. Depending on how many projects are in your workspace, you may see performance
improvements on subsequent runs as we're no longer re-building the project graph over and over
moon binary is ran.
Migrate from Turborepo
Turborepo is a popular task runner for Node.js based monorepos, but doesn't support all the
functionality that moon does. If you're looking to prototype moon, or migrate from Turborepo to moon
holistically, we now support a new command
moon migrate from-turborepo.
This command will migrate the
turbo.json file to moon applicable configuration files!
$ moon migrate from-turborepo
Because of the runner -> pipeline changes above, the
events were renamed to
Updated CLI options
--upstream option to
--remote, to better align with Git terminology, and removed the
--report option from
moon check and
moon run commands. Reports are now always created.
View the official release for a full list of changes.
- Added Bun as a tier 1 language (doesn't do much at the moment).
- Added a
.moon/workspace.ymlthat enforces a requirement on the running moon binary.
- Updated the
moon.ymlto be optional, excluding
- Internal improvements to remote caching and artifact uploading.
Expect the following in the v0.23 release!
- Improved task inheritance workflow.
- Glob support in task
- Project-level environment variables.