v0.20.1
Highlights
Fix: CLI_ROOT/PROJECT_ROOT dispatch (#90)
strut list, strut <stack> <cmd>, and the interactive TUI were all looking for stacks under $STRUT_HOME/stacks/ (the engine directory) instead of the user's project root. On a fresh install this made every user-facing stack command unable to find stacks that strut init and strut scaffold had correctly placed in the project.
Root cause: the entrypoint hardcoded CLI_ROOT="$STRUT_HOME" before find_project_root ran, so every $CLI_ROOT/stacks/… reference in lib modules targeted the engine.
Fix:
strutentrypoint now computesCLI_ROOT="${PROJECT_ROOT:-$STRUT_HOME}"afterfind_project_root. Stack lookups resolve against the project root; the engine-dir fallback is preserved for top-level commands that don't need a project (init,upgrade,--version,audit, migrate wizard) and for in-repo dev/test runs.- Clearer
Not inside a strut projecterror when a stack command is run outside any initialized project, with a pointer tostrut init. lib/local.sh: sourceanonymize.shfrom$STRUT_HOME(engine-shipped) instead of$CLI_ROOT, which would have broken onceCLI_ROOTresolved to the user's project.
Tests
- New
tests/test_cli_root_dispatch.bats— 6 end-to-end tests pinning inside-a-project, nested-subdir, outside-a-project, empty-engine-fallback, and override behavior. - Small updates to
test_cli_dispatch.bats,test_plugins.bats,test_tui.batsto keep fixture stacks underPROJECT_ROOTand accept the new error message. - Full suite: 1043 / 1043 green.
Upgrade
strut upgrade
# or
curl -fsSL https://raw.githubusercontent.com/gfargo/strut/main/install.sh | bashNo migration steps required. The fix is fully backwards compatible: explicit CLI_ROOT=… overrides still win, and engine-dir fallback behavior is unchanged for project-less invocations.
Full Changelog: v0.20.0...v0.20.1