# the-nix-way dev templates: forty six language shells you can drop into any repo

> A flake template collection that installs a reproducible toolchain into an existing project with one command, covering everything from Nim to Pulumi across three package managers.

**the-nix-way/dev-templates** — Dev environments for numerous languages based on Nix flakes [maintainer=@lucperkins]

- Repository: https://github.com/the-nix-way/dev-templates
- Stars: 2,372 · Forks: 188
- Language: Nix
- License: MPL-2.0
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/the-nix-way-dev-templates

## One command puts a toolchain in your project

The whole interface is `nix flake init` with a template reference. Two equivalent forms are documented, one pointing at FlakeHub and one at the GitHub repository directly:

```shell
nix flake init --template "https://flakehub.com/f/the-nix-way/dev-templates/*#${ENV}"
```

```shell
nix flake init -t github:the-nix-way/dev-templates#${ENV}
```

The second is shorter and needs no FlakeHub account, so it is the form you will actually type. The template name goes at the end after the hash, and it matches a directory name in the repository.

What gets created is a flake that exposes a development shell containing the language toolchain and its usual companions. The repository has `flake.nix` and `flake.lock` at the root, plus an `.envrc` file, which is the direnv entry point. It is a git repository with an MPL-2.0 license, 2,358 stars and 186 forks, and GitHub reports a last push on 2026-06-12.

The README is explicit that this is boilerplate and not a cage: you are free to add and remove packages as you see fit. That framing matters, because the alternative to adopting one of these templates is writing your own flake from scratch, which is the thing this repository exists to avoid.

## Two ways to enter the shell once it exists

After initialization you get the environment two ways, and the difference is whether the shell activates automatically.

With `nix-direnv` installed, you run `direnv allow` once per checkout and from then on entering the directory activates the environment. The `.envrc` in the repository is what makes that work, and this is the mode you want for daily work, since it removes the mental load of remembering to enter a shell before running anything.

Without it, you run `nix develop` to open the Nix defined shell for that directory. Nothing persists between shells, which is fine for a quick build or a one off command.

The example section shows the full sequence including creating a new project rather than modifying an existing one, using `nix flake new` with a target directory:

```shell
nix flake init --template "https://flakehub.com/f/the-nix-way/dev-templates/*#rust"

nix flake new --template "https://flakehub.com/f/the-nix-way/dev-templates/*#rust" ${NEW_PROJECT_DIRECTORY}
```

The distinction between `init` and `new` is the useful part. `init` drops the template into a directory you already have, which is how you adopt a toolchain for an existing project without disturbing its source. `new` scaffolds into a fresh path, which is what you want for a greenfield repository that should be reproducible from its first commit.

## What is actually in each template

The templates are opinionated in a specific, defensible way: each one pairs the language with the tools you would otherwise argue about. The Rust template, which the README uses as its worked example, includes Rust with cargo, Clippy and the other standard tools, and the version is resolved in a documented order of precedence.

```text
From the `rust-toolchain.toml` file if present
From the `rust-toolchain` file if present
Version
```

That ordering is the most interesting detail in the whole README, and it is worth internalizing. If your project already commits a toolchain file, the template respects it instead of overwriting your choice with its own default. That is the difference between a template you adopt once and one you fight every time nixpkgs moves.

The breadth is the other story. The Go template pairs Go with the standard tools plus `golangci-lint`. The C and C++ template is the most thorough at ten packages: clang-tools, cmake, codespell, conan, cppcheck, doxygen, gdb, gtest, lcov, vcpkg and vcpkg-tool. The Java template includes Java, Maven, Gradle and `jdtls`, so the language server is part of the deal rather than an extra. The Node template covers npm, pnpm and Yarn together with node2nix. The Hashicorp template is unusual in bundling ten tools including Packer, Terraform, Nomad, Vault, Terragrunt and tflint, and the Dhall template similarly bundles a dozen related packages.

Not every template is a language. There is one for Presenterm, one for Typst, one for Open Policy Agent with Conftest, one for PlatformIO, one for Jupyter, one for Protobuf with the Buf CLI and protoc, and one for Pulumi that pulls in six language SDKs at once because Pulumi is polyglot by nature.

## Lean is in the repository and missing from the table

Here is a documentation gap you will hit if you write Lean. The repository tree contains a `lean4/` directory, and the template contents section documents it with a heading for [`lean4`](./lean4/) listing Lean as its package. But the available templates table has no row for it.

Both facts are true. The table lists forty five entries and stops at Zig, with the language rows running Bun, C and C++, Clojure, C#, Cue, Deno, Dhall, Elixir, Elm, Empty, Gleam, Go, Hashicorp tools, Haskell, Haxe, Java, Jupyter, Kotlin, LaTeX, Nickel, Nim, Nix, Node.js, OCaml, Odin, Open Policy Agent, PHP, PlatformIO, Presenterm, PowerShell, Protobuf, Pulumi, Purescript, Python, R, Ruby, Rust, Scala, Shell, SWI-prolog, Swift, Typst, Vlang and Zig. Lean sits between LaTeX and Nickel alphabetically and would fit there, and the directory is present, so the template is usable via `nix flake init -t github:the-nix-way/dev-templates#lean4`.

The practical advice is to trust the directory listing in the repository over the table when you are looking for something specific. The same table has two entries whose links are malformed, `nim` and `swift`, both written without a trailing slash so they point at a file path rather than the directory. These are small blemishes on an otherwise carefully maintained README, and they are the kind of thing that comes from adding a language at the end and updating the table by hand.

Note also that the templates include the empty one, described as a dev template that is fully customizable, which is the sensible starting point when none of the forty six fit.

## Why a flake template beats a setup script

The argument for this approach is reproducibility, and the repository topics say so directly: `nix`, `flakes` and `reproducibility`. A setup script tells you which versions to install but leaves the resolution to whichever package manager happened to be on the machine, and that resolution changes over time. A flake pins it in `flake.lock`.

That matters most for the toolchains where a version bump breaks things. A Rust toolchain that shifts with a nightly channel, a Python template with pip, a Java template spanning Maven and Gradle: in each case the template encodes a set of versions the maintainers considered mutually compatible, and the lock file keeps that set stable even as nixpkgs moves underneath.

The second argument is onboarding. A new contributor clones the repository, runs `direnv allow`, and has the same environment as everyone else, including the same formatter, linter and language server configuration. There is no wiki page to read about which global tools to install first, which is the failure mode that makes onboarding on a project without this take a week.

The cost is Nix itself. Flakes are still marked experimental in some Nix channels, the dependency model is unfamiliar if you have only used apt or Homebrew, and a template that pins a toolchain is a template you have to update deliberately when the language moves. The README's own framing, that the templates are just boilerplate you are free to edit, is the answer to that: treat the flake as a starting commit that you own and adjust, not as a black box.

## Conclusion

The value of this collection is that it removes the argument, not the work. A team that disagrees about which formatter and which linter a Rust project should use can settle it with `nix flake init -t github:the-nix-way/dev-templates#rust` and commit the result, and the answer becomes reproducible on every machine including CI. Pick the template matching your language, run `direnv allow` or `nix develop`, and then edit the flake the way the README invites, by adding and removing packages as you see fit. One caution: Lean works even though it is missing from the table, so check the directory list rather than trusting the table alone.

## FAQ

### How do I use the Nix dev templates in an existing project?

Run nix flake init -t github:the-nix-way/dev-templates#NAME, where NAME matches a template directory such as rust or go. This adds a flake.nix and flake.lock to the current project without touching your source, and direnv allow or nix develop then activates the environment.

### Which languages do the dev templates cover?

The available templates table lists forty five, including Rust, Go, Python, Java, Kotlin, Ruby, C, C++, Haskell, Elixir, Nim, Zig, OCaml and several more. The repository tree actually holds forty six directories, since the lean4 template is present and documented but missing from the table.

### Do the templates pick a toolchain version for me?

They try to defer to your project first. The Rust template resolves its version from rust-toolchain.toml if present, then from rust-toolchain, and only falls back to its own default. Other templates carry their own default versions in the flake.

### Do I have to keep the whole template as installed?

No. The README states plainly that in all cases you are free to add and remove packages as you see fit, and that the templates are just boilerplate. Treat the generated flake as a starting commit you edit to match your project.

## Sources

- [Issues](https://github.com/the-nix-way/dev-templates/issues)
- [License: MPL-2.0](https://github.com/the-nix-way/dev-templates/blob/main/LICENSE)
- [README](https://github.com/the-nix-way/dev-templates/blob/main/README.md)
- [the-nix-way/dev-templates on GitHub](https://github.com/the-nix-way/dev-templates)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/the-nix-way-dev-templates