nix-lib-usage

Guides Nix library access patterns using inline prefixes, inherit, and scoped with expressions.

1|Updated Aug 21, 2023
One-click install
npx skills add https://github.com/jmuchovej/homelab --skill nix-lib-usage-jmuchovej
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: nix-lib-usage
Source: https://github.com/jmuchovej/homelab/tree/main/src/modules/ai-tools/skills/nix-lib-usage
Command: npx skills add https://github.com/jmuchovej/homelab --skill nix-lib-usage-jmuchovej

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Nix developers often misuse high-scope with lib; expressions, which breaks static analysis, disables IDE auto-completion, and introduces shadowing bugs. This Skill provides clear decision rules for choosing the right lib access pattern. ## Core Features & Use Cases - Decision Guide: Maps the number of lib functions used to the correct pattern: inline lib. prefix for 1-2 uses, inherit (lib) in a let block for 3+ uses. - Anti-Pattern Detection: Identifies module-level with lib; usage that breaks analyzers like nixd and nil. - Use Case: When writing a NixOS module that calls mkIf, mkOption, and types repeatedly, apply the inherit pattern so static analyzers and IDEs can resolve every function origin. ## Quick Start Ask the AI to review your Nix module and rewrite any high-scope with lib expressions using the appropriate lib access pattern.

Frequently Asked Questions about nix-lib-usage

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I avoid the with lib anti-pattern in Nix?

Avoid placing `with lib;` at module scope. Instead, use inline `lib.` prefixes for one or two function calls, or `inherit (lib) mkIf mkOption;` inside a let block when using three or more functions.

When should I use inherit (lib) instead of with lib in Nix?

Use `inherit (lib)` when a file references three or more lib functions. It explicitly names each function in a let binding, keeping origins clear for static analyzers while avoiding repetitive `lib.` prefixes.

Why does with lib break Nix IDE auto-completion?

High-scope `with lib;` brings every lib attribute into scope dynamically, so analyzers like nixd and nil cannot resolve where identifiers originate. This disables auto-completion and go-to-definition for all nested code.

Is with pkgs ever acceptable in Nix code?

Yes, `with pkgs;` is acceptable when tightly scoped to a single expression, such as `environment.systemPackages = with pkgs; [ git vim curl ];`. The problem is only high-scope usage spanning entire modules.

What problems does high-scope with lib cause in Nix modules?

It breaks static analysis visibility, disables IDE auto-completion, enables variable shadowing bugs, and makes function origins unclear in nested expressions. Module-level `with lib;` should never be used.