Dendritic Nix Configuration

This skill covers the Dendritic configuration pattern for Nix. It assumes familiarity with Nix flakes, the module system, and Home Manager. For those fundamentals, see the nix skill.

Core Principles

Dendritic is a configuration pattern, not a library or framework. It uses flake-parts to structure Nix configs around features (cross-cutting concerns) rather than hosts.

1. Every .nix file is a flake-parts module. One semantic meaning across the entire codebase -- no guessing whether a file is a NixOS module, a Home Manager config, or a package.

2. Features are the unit of composition, not hosts. Name files after how you use your environment -- the usability concern, not the tool or host. Ask "what experience am I configuring?" rather than "what package am I installing?" For example, scrolling-desktop.nix (enables niri on Linux and paneru on macOS) is better than niri.nix, and tui.nix or ai.nix are better than lists of specific packages. Simpler features can still be named after what they configure (ssh.nix, printing.nix), but the key insight is: features describe capabilities, hosts consume them. A host module is a thin list of feature imports.

3. Terminology: features vs aspects. A feature is the flake-parts module file (e.g., ssh.nix). An aspect is a flake.modules.<class>.<name> definition within that file. A single feature can contain multiple aspects (one per module class) plus flake-parts boilerplate. When the design guide says "aspect," it means the named module definition; when it says "feature," it means the enclosing file/directory.

4. flake.modules.<class>.<aspect> is the core mechanism. This requires importing inputs.flake-parts.flakeModules.modules in your flake-parts setup (see scaffolding template). Classes include nixos, darwin, homeManager, generic (for modules importable across any class -- it works because flake-parts omits the class constraint, so the module system accepts the options in any context), and any custom name you define. Aspects are referenced via inputs.self.modules.<class>.<aspect>. All features are auto-loaded by import-tree, so all aspect definitions are registered with flake-parts. However, an aspect only takes effect when something imports it -- either a host module's imports list or flake-parts boilerplate like flake.nixosConfigurations.

5. The dendritic pattern imposes no file organization restrictions. You are free to organize and name files however suits your mental model -- subdirectory structure is purely organizational and has no effect on module loading. That said, organizing by feature category helps navigation. A common convention from the design guide: