mosaicstack/stack
1
0
Fork 0
Code Issues 81 Pull Requests 1 Actions Packages Projects Releases 15 Wiki Activity

install.sh: unknown flags silently ignored — --next from main/mosaicstack.dev installs @latest and reports success #804

New Issue
Closed
opened 2026-07-16 21:29:05 +00:00 by jason.woltje · 1 comment
jason.woltje commented 2026-07-16 21:29:05 +00:00
Owner
Copy Link

Summary

Two compounding problems make the --next prerelease lane effectively unreachable via any documented install path, without ever surfacing an error.

1. Unknown flags are silently discarded

tools/install.sh on main ends its arg parser with:

*)                shift ;;

Any unrecognized flag is dropped with no warning and no non-zero exit.

2. --next only exists on the next branch

--next / MOSAIC_NEXT were added in #686/#688 on next only. They are absent from main's installer:

$ git show origin/main:tools/install.sh | grep -c -- '--next'
0
$ curl -fsSL .../raw/branch/next/tools/install.sh | grep -c -- '--next'
10

They are likewise absent from an already-installed ~/.config/mosaic/install.sh (framework v3, CLI 0.0.48).

Combined effect

curl -fsSL .../raw/branch/main/tools/install.sh | bash -s -- --next

silently drops --next, installs @latest (0.0.48), and prints ✔ Done. The user believes they installed the prerelease and got stable. Every retry looks like it succeeds. MOSAIC_NEXT=1 fails the same way — main's installer never reads the var.

Combined with #803 (mosaicstack.dev/install.sh returning 500), there is no documented path that reaches the next lane.

The lane itself is healthy — this is purely a bootstrap/UX defect:

✔  @next registry lane available: @mosaicstack/mosaic@0.0.49-next.1666, @mosaicstack/gateway@0.0.7-next.1666.

Workaround

Bootstrap the installer from the next branch directly:

curl -fsSL https://git.mosaicstack.dev/mosaicstack/stack/raw/branch/next/tools/install.sh | bash -s -- --next

Verified working — installs CLI 0.0.49-next.1666 + gateway 0.0.7-next.1666.

Proposed fix

  1. Fail loudly on unknown flags — warn + exit 1 with usage, instead of *) shift ;;. Fix on next and backport to main: main's installer is the one users bootstrap from, so leaving it silent there preserves the bug for everyone regardless of what next does. This is the higher-value half of the fix — it converts an unfalsifiable failure into a one-line error.
  2. Close the design gap — --next living only on next means the documented path can structurally never reach the next lane. Either:
    • teach main's installer to recognize --next and re-exec the next installer, or
    • document raw/branch/next/tools/install.sh as the official next-lane bootstrap in the README + docs/design/prerelease-next-dist-tag-pipeline.md.

Option (a) is preferable — it keeps a single advertised entry point and makes the lane discoverable rather than tribal knowledge.

Environment

Fedora Kinoite workstation, node v24.13.1, npm 11.8.0, framework v3, observed 2026-07-16.

## Summary Two compounding problems make the `--next` prerelease lane effectively unreachable via any documented install path, **without ever surfacing an error**. ### 1. Unknown flags are silently discarded `tools/install.sh` on `main` ends its arg parser with: ```bash *) shift ;; ``` Any unrecognized flag is dropped with no warning and no non-zero exit. ### 2. `--next` only exists on the `next` branch `--next` / `MOSAIC_NEXT` were added in #686/#688 on `next` only. They are absent from `main`'s installer: ``` $ git show origin/main:tools/install.sh | grep -c -- '--next' 0 $ curl -fsSL .../raw/branch/next/tools/install.sh | grep -c -- '--next' 10 ``` They are likewise absent from an already-installed `~/.config/mosaic/install.sh` (framework v3, CLI 0.0.48). ## Combined effect ``` curl -fsSL .../raw/branch/main/tools/install.sh | bash -s -- --next ``` silently drops `--next`, installs **@latest (0.0.48)**, and prints `✔ Done.` The user believes they installed the prerelease and got stable. Every retry looks like it succeeds. `MOSAIC_NEXT=1` fails the same way — main's installer never reads the var. Combined with #803 (mosaicstack.dev/install.sh returning 500), there is no documented path that reaches the next lane. The lane itself is healthy — this is purely a bootstrap/UX defect: ``` ✔ @next registry lane available: @mosaicstack/mosaic@0.0.49-next.1666, @mosaicstack/gateway@0.0.7-next.1666. ``` ## Workaround Bootstrap the installer from the `next` branch directly: ``` curl -fsSL https://git.mosaicstack.dev/mosaicstack/stack/raw/branch/next/tools/install.sh | bash -s -- --next ``` Verified working — installs CLI 0.0.49-next.1666 + gateway 0.0.7-next.1666. ## Proposed fix 1. **Fail loudly on unknown flags** — warn + `exit 1` with usage, instead of `*) shift ;;`. Fix on `next` **and backport to `main`**: main's installer is the one users bootstrap from, so leaving it silent there preserves the bug for everyone regardless of what `next` does. This is the higher-value half of the fix — it converts an unfalsifiable failure into a one-line error. 2. **Close the design gap** — `--next` living only on `next` means the documented path can structurally never reach the next lane. Either: - teach `main`'s installer to recognize `--next` and re-exec the `next` installer, or - document `raw/branch/next/tools/install.sh` as the official next-lane bootstrap in the README + `docs/design/prerelease-next-dist-tag-pipeline.md`. Option (a) is preferable — it keeps a single advertised entry point and makes the lane discoverable rather than tribal knowledge. ## Environment Fedora Kinoite workstation, node v24.13.1, npm 11.8.0, framework v3, observed 2026-07-16.
jason.woltje commented 2026-07-17 22:43:07 +00:00
Author
Owner
Copy Link

Post-merge non-blocking backlog (from independent exact-head RoR of PR #825, VERDICT APPROVE — neither is a defect, neither blocked the merge):

  1. --ref value-guard message clarity (tools/install.sh): rejecting any --ref value starting with - is a slightly blunt heuristic (a git ref can in contrived cases start with -, unrealistic for this project's branch naming), and the error reuses the generic "Unknown argument" wording rather than a --ref-specific message like "--ref value looks like a flag." Message-clarity only.
  2. Test-coverage breadth: the new spec covers the two PR scenarios (bare unknown flag, --ref-swallow) but not an explicit case for an unknown bare positional (e.g. justsomeword) — that path shares the same catch-all branch and was manually verified correct, but an explicit test would make coverage self-evident.

Filed for a future low-priority follow-up; not required for the shipped fix.

**Post-merge non-blocking backlog** (from independent exact-head RoR of PR #825, VERDICT APPROVE — neither is a defect, neither blocked the merge): 1. **`--ref` value-guard message clarity** (`tools/install.sh`): rejecting any `--ref` value starting with `-` is a slightly blunt heuristic (a git ref can in contrived cases start with `-`, unrealistic for this project's branch naming), and the error reuses the generic "Unknown argument" wording rather than a `--ref`-specific message like "`--ref` value looks like a flag." Message-clarity only. 2. **Test-coverage breadth**: the new spec covers the two PR scenarios (bare unknown flag, `--ref`-swallow) but not an explicit case for an unknown bare positional (e.g. `justsomeword`) — that path shares the same catch-all branch and was manually verified correct, but an explicit test would make coverage self-evident. Filed for a future low-priority follow-up; not required for the shipped fix.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
jason.woltje
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#804
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?