Upgrade gspot

Commit first, so you can go back. Read the release notes, pick a release, such as 1.2.0, and put it in place of <version> below.

npm

npm i -D -E @gspothq/cli@<version>
npx gspot apply
npx gspot install
npx gspot check

pnpm

pnpm add -D -E @gspothq/cli@<version>
pnpm exec gspot apply
pnpm exec gspot install
pnpm exec gspot check

Yarn

yarn add -D -E @gspothq/cli@<version>
yarn exec gspot apply
yarn exec gspot install
yarn exec gspot check

Bun

bun add -d -E @gspothq/cli@<version>
bunx gspot apply
bunx gspot install
bunx gspot check

mise

mise use --pin --tool-option allow_low_downloads=true npm:@gspothq/cli@<version>
mise exec -- gspot apply
mise exec -- gspot install
mise exec -- gspot check

gspot apply writes the new version to .gspot/version and updates the generated files. If it refuses a key of gspot.toml that the new version renamed or removed, the message names the close keys and links the release notes, which list each change. Edit gspot.toml, then run gspot apply again.

When gspot apply succeeds, review the diff and fix any findings. Then commit the generated files that changed, in .gspot/ and outside it, and either package.json with its lockfile or mise.toml, together. Commit gspot.toml too if you changed it to fix findings. Every other clone then runs gspot install. See Set up a clone.

If gspot apply names a JSON file it did not overwrite, delete that file and run gspot apply again. A JSON file has no header that marks it as generated, so gspot 0.1 kept that mark in a log that newer versions do not read.