wheels packages update

Updates are always explicit. There is no auto-update on reload and no implicit upgrade when running add on an already-installed package. This is the registry's defense against malicious version-bump attacks — every version change is the user's conscious choice.

Synopsis

synopsis

wheels packages update <name> --yes
wheels packages update --all --yes

Flags

| Flag | Description | |------|-------------| | --yes | Required. Confirms the update. Missing --yes throws Wheels.Packages.ConfirmationRequired. | | --all | Update every installed package. Still requires --yes. |

Mass update semantics

update --all --yes iterates every dir under vendor/ (except vendor/wheels/) that has a package.json. Failures in one package do not halt the others — the run continues and prints a per-package report at the end. If any package failed, the command throws Wheels.Packages.PartialUpdateFailure so the shell exit code is non-zero; the aggregated report is in extendedInfo.

Example

example output

$ wheels packages update wheels-sentry --yes
Installed wheels-sentry@1.1.0 → /Users/me/app/vendor/wheels-sentry
Restart the server (`wheels stop && wheels start`) to activate it.

$ wheels packages update --all --yes
Update report:
  wheels-sentry: updated → 1.1.0
  wheels-hotwire: already at 2.0.0
  wheels-basecoat: FAILED (Wheels.Packages.RegistryUnavailable — HTTP 503)
# exit 1 — partial failure