rig 1.1.0

rig

A convention-first .NET dev launcher, packaged as a dotnet tool. rig wraps the everyday dotnet loop — run, build, test, coverage, kill, publish — with project discovery, fuzzy matching, an interactive menu, shell completion, and per-repo custom commands. The overriding goal is less typing.

dotnet tool install --global rig
rig                 # interactive menu
rig test Archive    # run a test class (fuzzy match)
rig coverage --open # coverage + HTML report, opened

Why

The valuable, reusable part of a hand-rolled dev launcher is the ergonomics; the repo-specific lore (project names, test paths, build scripts) should be data, not code. rig is convention-first: in a vanilla single-app + single-test repo it needs zero configuration, and an optional .rig.json supplies only what can't be inferred.

Verbs

Bare rig opens an interactive menu: the everyday verbs up top, the rest under grouped ▸ sub-menus (Watch · Maintenance · Config); run/publish/kill then surface a project picker (default marked). Any unambiguous prefix of a verb also resolves (rig cove, rig reb). Watch run/test/build either way: the option (rig test -w) or the leading modifier (rig watch run, rig w r). Global flags: --dry-run/-n (print what would run/change, don't do it) and --quiet/-q.

Configuration (.rig.json, all optional)

Auto-discovered (so they stay out of config): the solution, the test project, the coverage runsettings, the coverage collector, the kill target, and the rebuild targets. What's left is only what can't be inferred:

{
  "$schema": "https://raw.githubusercontent.com/JohnCampionJr/rig/main/rig.schema.json",
  "defaultProject": "MyApp",                                    // when several are runnable
  "test": { "envPresets": { "log": { "MYAPP_LOG": "1" } } },    // `rig test --log`
  "commands": { "deploy": "./deploy.sh" },                      // custom verbs (npm-scripts style)
  "aliases": { "coverage": "cov" },                             // override a verb's short alias
  "exclude": ["*Bench", "*.Demo", "*Spike"],                    // hide projects from the pickers
  "quiet": false                                                // suppress the `→ command` echo
}

rig init scaffolds this; rig setup walks you through the settable prefs and writes them to the repo or user-wide file for you; rig run --remember / rig default <p> write defaultProject (all comment-preserving). .env / .env.local are loaded automatically (dotenv precedence).

User-wide config (~/.rig.json)

A ~/.rig.json (override the path with $RIG_GLOBAL_CONFIG) applies to every repo. The repo's .rig.json is layered on top — repo wins per key, dictionaries (env, aliases, commands) union. Good for personal aliases and, especially, a ReportGenerator Pro license you set once and never commit:

// ~/.rig.json
{ "coverage": { "license": "your-pro-key" }, "aliases": { "coverage": "cov" } }

A repo's scaffolded blank coverage.license: "" falls through to this global key (empty strings count as unset), so the license lives in exactly one un-committed place. rig info shows the global path and merged result.

Coverage

Coverage renders in-process via the bundled ReportGenerator — no separate install. Single-file inline report by default, --full for the multi-file report, --open to open it; the headline line %·branch % prints to the console. --min <pct> gates line coverage (non-zero exit if below — handy in CI). Persist any of these as defaults in .rig.json — coverage.open, coverage.full, coverage.min (the matching CLI flag always wins). ReportGenerator Pro features unlock via the REPORTGENERATOR_LICENSE env var (or .rig.json coverage.license) — rig bundles only the free Apache-2.0 engine.

Completion

Self-contained — no dotnet-suggest required. Add one line for your shell; it calls rig's own [suggest] directive, so it behaves identically on macOS, Linux, and Windows:

# zsh — ~/.zshrc
eval "$(rig completion zsh)"
# bash — ~/.bashrc
eval "$(rig completion bash)"

# pwsh — $PROFILE
Invoke-Expression (& rig completion pwsh | Out-String)

Tab then completes verbs, aliases, and discovered project/test names.

Building from source

dotnet test Rig.slnx     # or: dotnet test tests/Rig.Tests/Rig.Tests.csproj

See docs/DESIGN.md for architecture and the rationale behind the key decisions, and CHANGELOG.md for release history.