Beyond NixOS Templates

The same DOM + traits + rules model works for any declarative config system. The trait’s class function decides what gets built — you swap in nvf, terranix, or anything else.

Neovim configurations

Two neovim variants from one DOM:

graph TD
    R["nest.neovim (namespace)"]
    M["minimal\ntrait: vim"]
    F["full\ntrait: vim\nenableLSP: true"]

    R --> M
    R --> F

The vim trait’s class function calls nvf.lib.neovimConfiguration. Rules apply to any vim node — shared config once, variant config by attribute or selector.

Outputs land in packages.x86_64-linux — install either config with nix profile install .#minimal or .#full.

Terraform with Terranix

Define VM infrastructure as Nest nodes. The vm trait’s class function calls terranix.lib.terranixConfiguration, producing JSON Terraform configs. Same selector model — target VMs by environment, role, or attribute.

Development Environments

Use Nest as a module inside a flake-parts flake. Nest outputs become available as perSystem outputs alongside devshells, packages, and checks.

flake.nix

outputs = inputs: inputs.flake-parts.lib.mkFlake { inherit inputs; } (
  inputs.import-tree ./modules
);

Your modules/ directory mixes Nest trait/DOM/rules modules with flake-parts modules freely.

Custom top-level outputs

flake-file auto-generates flake.nix from a declarative outputs.nix. Nest fits naturally — your outputs file stays clean, inputs stay consistent.

---

Custom class functions

Any class function that takes modules and returns a config value works.

Mixed outputs

One flake can output NixOS configs, HomeManager configs, and packages — all from the same DOM.

---

nvf-standalone template Two neovim configs managed with Nest.

terranix-demo template Terraform infrastructure as Nest nodes.

flake-parts-modules template Nest inside a flake-parts flake.