Managing monorepos can get messy quickly. I've used Changesets mostly in pure JS/TS environments and it's been a lifesaver for versioning. Interesting read on how you're handling the polyglot aspect to keep things unified.
Because Nix is a package manager not tied to one programming language ecosystem, I can install all the tools for every language I need, and have the tooling consistent and modular, even between monorepos.
For formatting I usee treefmt-nix, which quickly format all syntaxes in my repo (.nix, .rs, .md, etc.) by calling individual formatters (installed via Nix), such as rustfmt, mdformat, nixfmt, etc.
For git hooks I use lefthook-nix, which automatically installs my git hooks using lefthook. husky, cargo-husky, etc. are great, but they assume you're mainly using one tech stack. lefthook is like pre-commit, but with significantly better dependency chain. (I tried one time to bust the Nix cache and had to download and compile both the .NET runtime and the Swift runtime... it reminded me my dependency footprint could be smaller.)
For Cargo workspaces in Rust I use workspace-level linter rules, so all new crates can inherit the same rules.
As the author, I also love `just` and I have the CI steps as `just fmt`, etc.
This means the same commands I type work in CI, so there's not a parallel environment I have to maintain.
I have a `just ci` for running all the steps at once locally, but in GitHub/Forgejo Actions, I like to split them into separate Actions steps for better rendering on web. But `just ci: fmt lint ...` is just an alias, so very little repetition here.
We basically do the same for https://github.com/scalar/scalar/
Publishing to npm, PyPi, Maven Central, crates.io, NuGet… all using changesets.
Managing monorepos can get messy quickly. I've used Changesets mostly in pure JS/TS environments and it's been a lifesaver for versioning. Interesting read on how you're handling the polyglot aspect to keep things unified.
I handle polyglot monorepos using Nix.
Because Nix is a package manager not tied to one programming language ecosystem, I can install all the tools for every language I need, and have the tooling consistent and modular, even between monorepos.
For formatting I usee treefmt-nix, which quickly format all syntaxes in my repo (.nix, .rs, .md, etc.) by calling individual formatters (installed via Nix), such as rustfmt, mdformat, nixfmt, etc.
For git hooks I use lefthook-nix, which automatically installs my git hooks using lefthook. husky, cargo-husky, etc. are great, but they assume you're mainly using one tech stack. lefthook is like pre-commit, but with significantly better dependency chain. (I tried one time to bust the Nix cache and had to download and compile both the .NET runtime and the Swift runtime... it reminded me my dependency footprint could be smaller.)
For Cargo workspaces in Rust I use workspace-level linter rules, so all new crates can inherit the same rules.
As the author, I also love `just` and I have the CI steps as `just fmt`, etc.
This means the same commands I type work in CI, so there's not a parallel environment I have to maintain.
I have a `just ci` for running all the steps at once locally, but in GitHub/Forgejo Actions, I like to split them into separate Actions steps for better rendering on web. But `just ci: fmt lint ...` is just an alias, so very little repetition here.
Here's a lefthook-nix + treefmt-nix guide: https://simonshine.dk/articles/lefthook-treefmt-direnv-nix/
Here's a GitHub Actions + Nix guide: https://simonshine.dk/articles/speeding-up-ci-with-nix/
Here's an example project that uses it: https://github.com/sshine/walltime-rs
Here's a "how much Nix should I swallow at once?" guide: https://simonshine.dk/articles/three-levels-of-nix/
Here's a Forgejo Actions runner that builds and pushes an OCI image to a registry without Docker: https://git.shine.town/infra/runners/src/branch/main/.forgej...
Would love to see more of the Docker step.