Using Changesets in a polyglot monorepo(luke.hsiao.dev)
luke.hsiao.dev
Using Changesets in a polyglot monorepo
https://luke.hsiao.dev/blog/changesets-polyglot-monorepo/
6 comments
check out https://bumpy.varlock.dev - still a bit of work to do to make other languages even easier, but it fixes a few things with changesets around custom publishing.
Not intending this to be an ad, but a friend of mine has been working on a changesets-based tool that has native polyglot support: https://github.com/bruits/sampo
Hopefully easier than hacking around changesets, but less mature, of course.
(Disclaimer: Him and I are in the same org and I have sent PRs to said tool)
Hopefully easier than hacking around changesets, but less mature, of course.
(Disclaimer: Him and I are in the same org and I have sent PRs to said tool)
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.
We basically do the same for https://github.com/scalar/scalar/
Publishing to npm, PyPi, Maven Central, crates.io, NuGet… all using changesets.
Publishing to npm, PyPi, Maven Central, crates.io, NuGet… all using changesets.
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...
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.