fix(cli): hard-fail invalid WHEELS_FRAMEWORK_PATH instead of silent fallback (#2215)#2222
Merged
Merged
Conversation
…allback (#2215) When WHEELS_FRAMEWORK_PATH was set but pointed at a non-existent directory, resolveFrameworkSource() appended the path to the search list and fell through to tier 2/3 auto-discovery. The user's explicit override was silently ignored — a typo or stale path could resolve to a surprising framework version instead of failing loudly. Throw Wheels.FrameworkPathInvalid when the override is set but directoryExists() is false. Picocli maps this to exit code 1 (same mechanism as #2216). Error message echoes the bad path and suggests both remedies (unset or point at a valid source). Moved the `override` var out of the try so the throw isn't swallowed by the catch-all that guards getenv() availability. Extended test-new-exit-codes.sh with a GH #2215 section: invalid path must exit non-zero, error must echo the bad path, no partial scaffold. Verified RED pre-fix (exit 0, silent fallback) and GREEN post-fix.
bpamiri
force-pushed
the
claude/blissful-elion-ebeb75
branch
from
7e318cf to
9699f6f
Compare
This was referenced Apr 22, 2026
Closed
bpamiri
added a commit
that referenced
this pull request
Apr 22, 2026
…rce checkout (#2223) (#2225) When invoked as `wheels`, LuCLI loads modules from ~/.wheels/modules/wheels/. If that path is a real directory holding a pre-install copy of Module.cfc, edits a contributor makes under cli/lucli/ in a source checkout silently do not take effect — surfaced during #2222, where the merged #2216 fix kept exit-0'ing locally because the installed module was a pre-fix copy. `wheels doctor` now detects this when run from a wheels source checkout (projectRoot contains cli/lucli/Module.cfc + vendor/wheels/). The installed Module.cfc is inspected three ways: - symlink to the checkout → pass - real file, bytes match → pass (stale but harmless this moment) - real file, bytes diverge → warn, with a `rm -rf && ln -s` remediation command in the recommendations section The check is a no-op outside source checkouts and when the installed path is the checkout's own cli/lucli/ (dev-symlinked install). Symlink detection and byte comparison go through java.nio.file.Files for cross-engine parity. Closes #2223.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2215.
Summary
resolveFrameworkSource()used to append an invalidWHEELS_FRAMEWORK_PATHto the search list and silently fall through to tier 2/3 auto-discovery — the user's explicit override was ignored, and a typo'd or stale path could resolve to a surprising framework version.Wheels.FrameworkPathInvalidwhen the env var is set butdirectoryExists()is false. Picocli maps this to exit code 1 (same mechanism as fix(cli): wheels new exits non-zero on framework-not-found (#2211) #2216).vendor/wheels/).Structural note
Moved
overrideout of thetryblock so the newthrowisn't swallowed by the catch-all that guardsgetenv()availability. The catch still only suppresses Java/env-access errors (overridestays empty → tier 1 skipped → fallbacks engage normally).Acceptance criteria (from #2215)
WHEELS_FRAMEWORK_PATH=/does/not/exist wheels new fooexits non-zero with a clear messageWHEELS_FRAMEWORK_PATH=/valid/path wheels new foostill worksTest plan
cli/lucli/tests/test-new-exit-codes.shwith aGH #2215section that:WHEELS_FRAMEWORK_PATHto a non-existent pathWheels.FrameworkPathInvalidmessage)WHEELS_FRAMEWORK_PATH=…/vendor/wheels wheels new happyappexits 0, scaffoldsvendor/wheels/as expected.bash cli/lucli/tests/test-new-exit-codes.shafter local install to confirm both wheels new exits 0 when framework-not-found, masks fatal errors to automation #2211 and wheels new: explicit WHEELS_FRAMEWORK_PATH should hard-fail when it doesn't exist #2215 sections pass.Related