Update grim itself
$ grim self-updateOnce a day grim looks for a newer release of itself, and when there is one, any command opens with A new version of grim is available. That line is the usual reason to run grim self-update. The other is a fix you were told has been released.
It updates the tool and only the tool. A project's core and modules move with grim update, and its Docker files with grim upgrade.
Usage
$ grim self-update # move to the newest release, if there is one
$ grim self-update --force # download and install it even when already on itIt runs from anywhere. It only works on an installed phar; run from a source checkout it stops with grim is not running as a PHAR; reinstall via the install script first.
Arguments and options
Update grim CLI to the latest version
Usage
grim self-update [-f|--force]Options
| Option | Description |
|---|---|
-f, --force |
Force update even if version appears current |
What it actually does
- Asks GitHub for the latest release and compares it with the running version. When there is nothing newer it prints
already up to dateand ends. - Downloads
grim.phartogrim.phar.new, next to the running file, using your stored GitHub token. - Compares the checksum with the release's
grim.phar.sha256. The outcome is written to the log. A mismatch is recorded there and does not stop the update. - Runs the download with
--version. A file that does not start, or prints no version, is deleted and the update fails. The phar you had stays in place. - Swaps the file. On macOS and Linux it is one rename, so there is no moment without a working
grim. On Windows the running file is locked: the new one is staged and thegrim.batwrapper swaps it in as the command exits, then prints the new version.
Every step goes to ~/.grim/selfupdate.log, and a failure prints the path to it.
Pitfalls
could not check is usually the network
could not check (no network or GitHub unreachable) means the release lookup failed and nothing was downloaded. Check that github.com is reachable, then read the end of the log with grim doctor --logs.
A missing token shows only in the log
The terminal says failed to resolve release assets via GitHub API. The reason is further up in the log: No GitHub token found in grim auth storage or composer auth.json. Run grim auth:login and update again.
An old Windows wrapper finishes the job after you leave
Update will complete after this process exits (legacy wrapper …) means your grim.bat predates the in-place swap. The rename happens in the background, and you only see the new version in a fresh PowerShell. Run the Windows install script once to get the current wrapper.
After it finishes
Templates ship inside grim, so a newer grim may carry newer Docker files than your projects have. In each project you work on, bring them in line.
$ grim upgradeQuestions
Can I go back to an older release?
Not with this command. It knows only the latest release, and --force reinstalls that one.
Does it change my projects?
No. It replaces one file on your machine. A project changes only when you run grim upgrade or grim update inside it.
Related spells
grim upgrade
Renew the infrastructure files
Rewrite the Docker and nginx files of a project from the templates of the grim you have installed.
grim update
Board the newest train
Move core, every module and every theme onto the newest release train grim.json allows, or a single module within the train it is on.
grim doctor
Check your circle
Check every tool grim expects on this machine, and the project you are standing in, and say what to do about what is missing.
grim auth:login
Log grim in to GitHub
Give grim a GitHub token, from your gh login or a personal access token, and hand the same token to Composer and Docker.