6.1 How to structure a real Nix project

One Nix expression is easy. A real Nix project has many: multiple subprojects, mixed languages, tests, docs, tooling. This lesson lays out the standard Nix project structure, what default.nix, shell.nix, release.nix and flake.nix are each for, and why a good layout shrinks rebuild times and keeps your CI config from growing forever.

In this video

• Why each subproject should describe its own build, and why subproject A should never know where B lives
• The entry point files every outside consumer expects, and the job each one does
• How small per-package sandboxes improve build times and caching compared to one big build
• Turning CI into a plain Nix build runner instead of ever-growing YAML files
• Documentation, test coverage reports, formatters and linters as buildable outputs anyone can discover with two commands

After this lesson

You can open any repository in your company, no matter the language, and know where the builds, shells, tests and docs live. And you know the shape your own projects should grow into, with or without flakes.