DEV Community: Timur Lolaev

I wanted Copier in Rust, so I wrote rootstock

Timur Lolaev — Sun, 01 Nov 2026 01:58:52 +0000

I write Rust for a living, and over the last couple of years the tools around me quietly turned into Rust too. On the frontend, Biome does what ESLint and Prettier used to. In Python land it's Ruff and uv. They're fast, they ship as one binary, and there's nothing to set up besides the binary itself.

Project templates were the exception. The best tool I know for them is Copier, and it's genuinely good. But it's Python, so every machine and every CI job that touches a template needs Python and pipx first. I wanted the same thing as one binary. That's rootstock.

Creating a project is the easy part

Plenty of tools can create a project from a template: cargo-generate, kickstart, cookiecutter. They render the files and that's it. From then on the project and the template live separate lives.

That's fine for a one-off. It hurts when the template keeps changing. Think shared CI workflows, lint configs, a service skeleton your team uses everywhere. Someone fixes the CI in the template, and now there are twenty projects with the old version, each with its own local edits. Copying the fix by hand gets old fast.

Copier's answer is to remember how the project was made and replay the template's changes on top of it. rootstock does the same.

What an update looks like

rootstock new renders the template and writes a small record, .rootstock.toml, next to your files: the template source, the tag and exact commit, your answers, and the list of files it wrote.

$ rootstock new gh:acme/service-template my-app --data project_name=my-app --defaults
created my-app from gh:acme/service-template v1.0.0

Later the template ships v1.1.0. It bumps actions/checkout in CI and adds --all-targets to the test and lint targets in the Makefile. Meanwhile you've added a fmt target and made clippy stricter.

$ rootstock update
updated to v1.1.0
markers Makefile
1 conflict

The CI bump and the new test line went in on their own. Your fmt target is still there. The one line you both changed is marked:

lint:
<<<<<<< project
    cargo clippy -- -D warnings
=======
    cargo clippy --all-targets
>>>>>>> template v1.1.0

You fix it, run rootstock check, commit. The update is a plain diff in git, so it's easy to review and easy to throw away.

How the merge works

Under the hood rootstock renders the template twice in temp directories: the old version with the answers from the record (the base), and the new version with the current answers (the target). Then it goes path by path and compares base, target and what's in your project.

If only the template changed a file, you get the template's version. If only you changed it, nothing happens. If both did, the text goes through git merge-file, which is what Copier uses too. I picked the git CLI over a merge library on purpose: the result matches Copier, the markers look like the ones everyone already knows, and your own git config doesn't leak into it.

Some cases can't be merged at all, and rootstock doesn't pretend they can. A binary file you edited keeps your copy and gets the template's version next to it as name.rootstock-new. A file you deleted but the template changed stays deleted and gets reported. Files marked as starter (a README, say) are written once and never touched again.

Want to change an answer later? rootstock update --data ci=false renders the base with the old answers and the target with the new ones, even when the version stays the same.

Conflicts are an exit code

Every case that needs a human ends with exit code 2 and one line per problem on stdout: markers Makefile, binary logo.png and so on. Everything else goes to stderr.

That makes it easy to automate. My harness template (agent tooling, hooks and CI for my projects) has a daily workflow in each project that runs rootstock update, opens a PR and labels it when the exit code is 2. Clean minor and patch updates merge themselves once CI is green. The conflicting ones wait for me.

rootstock check runs in CI without network access and fails on leftover markers or side files, so a half-resolved conflict can't slip into main.

Coming from Copier

rootstock import-copier converts a Copier template, a project generated by Copier, or both if they live in the same directory. It writes nothing unless the whole conversion succeeds. Old template tags don't need converting – update reads versions that only have copier.yml and converts them in memory.

For harness I checked that the converted template renders byte for byte like Copier 9.19 for every combination of its answers. That was my bar for calling the import done.

What it doesn't do (yet)

rootstock supports the part of Copier my templates use. _migrations, Jinja extensions and some question types aren't there, and the import stops with the full list if your template needs them. It's v0.1.0, so expect rough edges.

Try it

cargo install rootstock --locked

There are also prebuilt binaries for Linux (static, musl), macOS and Windows on GitHub Releases. The only thing it needs at runtime is git.

If you maintain templates and something here doesn't fit how you work, open an issue. I'd like to hear about it.

bodasooqa / rootstock

Create projects from versioned git templates and update them by three-way merge, without losing the project's edits. A single Rust binary, like Copier.

Project templates that keep growing after you use them.

Create a project from a versioned git template, then update it to every new template version
with a real three-way merge: your edits stay, the template's improvements arrive, conflicts are never silent.

Website · Install · Quick start · How updates work · Commands · Writing a template · Coming from Copier

In grafting, the rootstock is the root system, and the scion is the branch grafted onto it. The scion grows its own way, and the root keeps feeding it. A rootstock project works the same way. The template is the root and the project is the scion: the project goes its own way, and improvements to the template keep reaching it.

Why rootstock

Most scaffolding tools stop once the project is created. That is fine for a one-off, but not for a template that keeps changing: shared CI, lint…

View on GitHub

I built nvm-style account manager for Claude Code

Timur Lolaev — Thu, 21 May 2026 07:00:00 +0000

If you use Claude Code with more than one account – personal and work, or one per client – you know the dance. claude opens, you realize you're under the wrong account, you /logout, /login, sit through the OAuth browser flow, then forget which account you're in by the time you switch projects again.

I built claudenv to make this stop happening.

claudenv use work
claude   # automatically under your work account

cd ~/projects/clientA
# auto-switches if you opted in, or:
claudenv use personal

That's it. The same claude binary, just pointed at different config directories via the official CLAUDE_CONFIG_DIR environment variable. No symlinks, no patching files in place, no daemons.

How it works

Claude Code reads its config from ~/.claude by default, but respects CLAUDE_CONFIG_DIR if set. claudenv keeps one directory per account under ~/.claudenv/accounts/<name>/ and points the env var at the right one. Each account has its own OAuth state, settings, MCP servers, the whole thing.

There are three layers of state, exactly like nvm:

Global default – what you set with claudenv use work, persists across shells
Per-project override – a .claudenvrc file in your repo, picked up via walk-up resolution like .nvmrc
Shell-session override – .claudenvrc auto-switches on cd if you enable the hook Set a default, override per-project, forget about it.

Why not just claude-switch or claudectx?

There are other tools in this space – I want to be upfront about that.

claude-switch uses the same CLAUDE_CONFIG_DIR mechanism, but the workflow is per-launch: claude-switch work runs Claude under that profile, every time you start a session. If you prefer being explicit on every invocation, use it – it's a fine tool.

claudectx and a few others go a different route entirely, symlinking or patching ~/.claude.json in place. That works too, but it's stateful in a way I didn't want. If the symlink breaks or a patch fails halfway, you end up in a weird state that's hard to debug.

claudenv is for people who switch accounts more than once a day and don't want to type the profile name every time. If your projects are clearly tied to specific accounts, .claudenvrc + auto-switch means you basically never think about it again.

Install

curl -fsSL https://raw.githubusercontent.com/bodasooqa/claudenv/main/install.sh | bash

Or with wget, or download and inspect first – instructions are in the README.

Bash or zsh, that's the only requirement. No Node, no Python, no Homebrew, no extra dependencies. Twenty lines into ~/.zshrc, you're done.

What's next

A few things on the roadmap: a claudenv self-update command, a Homebrew tap once there's a real release cadence, and a wrapper that makes GUI-launched IDEs (Cursor, VS Code from the Dock or Spotlight) pick up the active profile – currently that's a known limitation with launchd not reading shell rc files, documented in the README.

If it solves your problem, a star helps me prioritize what to build next. Issues and PRs welcome.

bodasooqa / claudenv

nvm-style account manager for Claude Code. Switch profiles via CLAUDE_CONFIG_DIR, with per-project .claudenvrc and auto-switch on cd.

claudenv

An nvm-style account manager for Claude Code. Set a default account, override per-project with .claudenvrc, optionally auto-switch on cd. Zero dependencies.

claudenv import default       # save current ~/.claude as 'default' (auto-activated — first profile)
claudenv add work             # create new empty slot
claudenv use work             # switch this shell + set as global default
claude                        # /login here, isolated from 'default'

When accounts/ is empty, the first import or add auto-activates the new profile so you don't have to follow with claudenv use. Subsequent ones don't change the active profile.

Is this for you?

Claude Code already supports CLAUDE_CONFIG_DIR for account isolation. Several tools wrap this — pick the one that fits how you work:

claudenv	claude-switch
Mental model	Set a default, work normally	Specify account on every launch
Typical command	`claude` (after `claudenv use work`)	`claude-switch work`
Per-project config	`.claudenvrc` (walk-up resolution)	✗

…

View on GitHub