Skip to content

Wheels CLI ignores --no-sqlite argument #2855

Closed

Description

@teleotic

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:

  1. Create new app with wheels new test_app --no-sqlite
  2. 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):

  • OS: Ubuntu 26.04 LTS, Windows 11 Pro 25H2
  • Version: Wheels 4.0.2 (Linux), 4.0.3-snapshot.1966 (bleeding-edge)

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.

Activity

  1. wheels-bot commented on Jun 4, 2026

    @wheels-bot
    Contributor

    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:

    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:

    1. 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.
    2. 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.

    <!-- wheels-bot:triage:2855 -->
    <!-- wheels-bot:triage-class:bug -->
    <!-- wheels-bot:triage-confidence:medium -->

  2. wheels-bot commented on Jun 4, 2026

    @wheels-bot
    Contributor

    Wheels Bot — Fix proposed

    Draft PR: #2856

    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.

  3. added 3 commits that reference this issue on Jun 5, 2026
    5661859
    d1cdbe3
    45e5fb1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions