You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Using wheels new --no-sqlite incorrectly results in SQLite database files still being created, and SQLite datasource code being generated. This was partially addressed in issue #2621 but the behavior remains. On investigation, the --no-sqlite argument is never passed through to Wheels CLI module.
To Reproduce
Steps to reproduce the behavior:
Create new app with wheels new test_app --no-sqlite
App is erroneously created with a SQLite database
Expected behavior
The SQLite database and related code should not be generated.
Desktop (please complete the following information):
Additional context
After testing several variations, it appears that no command line argument beginning with --no- is passed through to the Wheels CLI module (/wheels/cli/lucli/Module.cfc). Therefore options.noSQLite is never set to true and the default behavior continues. I have not determined whether this is a Wheels issue or a limitation with the upstream LuCLI tool. (LuCLI has a --no-agents option that may be causing a parsing problem, but this is just speculation.)
A possible quick fix is renaming the command line argument. For instance --nosqlite correctly passes through.
The report describes observable wrong behavior with a clear "what happened / what I expected / steps to reproduce" structure, and confirms it against the prior fix attempt in #2621 / #2624. From the issue:
After testing several variations, it appears that no command line argument beginning with --no- is passed through to the Wheels CLI module … --nosqlite correctly passes through.
Suspected layer
cli — see cli/lucli/Module.cfc and cli/CLAUDE.md for canonical patterns.
The wheels new handler at cli/lucli/Module.cfc:746 already parses --no-sqlite correctly (line 791-792, default options at line 776, and scaffoldNewApp consumes opts.noSQLite at lines 4554-4562, 4578, 4608). So the in-handler logic from #2624 is intact — the bug is that the --no-sqlite token never reaches getArgs(arguments) in the first place. That points upstream at the LuCLI argv layer, which appears to strip or reroute --no-* flags (the reporter speculates a conflict with LuCLI's own --no-agents flag).
Fix sketch
Two plausible shapes:
Rename / alias the flag in Module.cfc — add --nosqlite (already works per the reporter) as the canonical form, document both --no-sqlite and --nosqlite, and update the wheels new help text (cli/lucli/Module.cfc:759, 766). Same change pattern needed for --no-open-browser (line 793-794) if it's also affected. Quick, local, low-risk.
Fix the upstream LuCLI argv handling so all --no-* flags pass through to module functions. Larger blast radius — touches the LuCLI runtime that the wheels binary is built on, not just Module.cfc.
Either approach should ship with a verification step (run wheels new test_app --no-sqlite and confirm db/development.sqlite is NOT created and lucee.json has "{}" for datasources). Recommend (1) for fast resolution and filing (2) separately if confirmed as a LuCLI runtime issue.
Confidence: medium
Symptom and rough fix shape are clear, but the root cause sits at the LuCLI argv boundary (not Wheels code) and the two fix paths have meaningfully different scopes — that's a design trade-off propose-fix should weigh, not a mechanical one-liner.
Spec: cli/lucli/tests/specs/commands/NewCommandArgvSpec.cfc — failing → passing
Implementation: cli/lucli/Module.cfc (argsFromCollection()'s false branch now re-emits --no-<key> instead of dropping the entry); test fixture cli/lucli/tests/_fixtures/commands/ModuleArgvProbe.cfc exposes the private helper for unit testing.
The triage proposed two paths (rename/alias vs. fix the upstream argv handling). Investigation showed the conversion lives inside argsFromCollection() in cli/lucli/Module.cfc itself, not in the LuCLI runtime — so the "upstream" path turned out to be a small local change that fixes every --no-* flag at once (--no-sqlite, --no-open-browser, --no-routes, --no-test-db). That is what landed.
A human review is required before merge. Reviewer A and Reviewer B will weigh in shortly. Doc updates (MDX guides, .ai/wheels/, CLAUDE.md) are handled separately by bot-update-docs.yml.
Activity
wheels-bot commentedon Jun 4, 2026
Wheels Bot — Triage
Classified as bug.
The report describes observable wrong behavior with a clear "what happened / what I expected / steps to reproduce" structure, and confirms it against the prior fix attempt in #2621 / #2624. From the issue:
Suspected layer
cli— seecli/lucli/Module.cfcandcli/CLAUDE.mdfor canonical patterns.The
wheels newhandler atcli/lucli/Module.cfc:746already parses--no-sqlitecorrectly (line 791-792, default options at line 776, andscaffoldNewAppconsumesopts.noSQLiteat lines 4554-4562, 4578, 4608). So the in-handler logic from #2624 is intact — the bug is that the--no-sqlitetoken never reachesgetArgs(arguments)in the first place. That points upstream at the LuCLI argv layer, which appears to strip or reroute--no-*flags (the reporter speculates a conflict with LuCLI's own--no-agentsflag).Fix sketch
Two plausible shapes:
Module.cfc— add--nosqlite(already works per the reporter) as the canonical form, document both--no-sqliteand--nosqlite, and update thewheels newhelp text (cli/lucli/Module.cfc:759, 766). Same change pattern needed for--no-open-browser(line 793-794) if it's also affected. Quick, local, low-risk.--no-*flags pass through to module functions. Larger blast radius — touches the LuCLI runtime that thewheelsbinary is built on, not justModule.cfc.Either approach should ship with a verification step (run
wheels new test_app --no-sqliteand confirmdb/development.sqliteis NOT created andlucee.jsonhas"{}"for datasources). Recommend (1) for fast resolution and filing (2) separately if confirmed as a LuCLI runtime issue.Confidence:
mediumSymptom and rough fix shape are clear, but the root cause sits at the LuCLI argv boundary (not Wheels code) and the two fix paths have meaningfully different scopes — that's a design trade-off propose-fix should weigh, not a mechanical one-liner.
<!-- wheels-bot:triage:2855 -->
<!-- wheels-bot:triage-class:bug -->
<!-- wheels-bot:triage-confidence:medium -->
wheels-bot commentedon Jun 4, 2026
Wheels Bot — Fix proposed
Draft PR: #2856
Spec:
cli/lucli/tests/specs/commands/NewCommandArgvSpec.cfc— failing → passingImplementation:
cli/lucli/Module.cfc(argsFromCollection()'sfalsebranch now re-emits--no-<key>instead of dropping the entry); test fixturecli/lucli/tests/_fixtures/commands/ModuleArgvProbe.cfcexposes the private helper for unit testing.The triage proposed two paths (rename/alias vs. fix the upstream argv handling). Investigation showed the conversion lives inside
argsFromCollection()incli/lucli/Module.cfcitself, not in the LuCLI runtime — so the "upstream" path turned out to be a small local change that fixes every--no-*flag at once (--no-sqlite,--no-open-browser,--no-routes,--no-test-db). That is what landed.A human review is required before merge. Reviewer A and Reviewer B will weigh in shortly. Doc updates (MDX guides,
.ai/wheels/,CLAUDE.md) are handled separately bybot-update-docs.yml.Merge branch 'develop' into fix/bot-2855-wheels-cli-ignores-no-sqlite…
fix(cli): re-emit --no-* flags so LuCLI-converted negations reach com…
feat(cli): add ArgSpec typed argument-spec builder for CLI subcommands (
refactor(cli): migrate 8 leaf commands to ArgSpec, dropping the argv …