# Upgrade gspot

> Install a new gspot version and update the generated files.

Commit first, so you can go back. Read the [release notes](https://github.com/stefanionescu/gspot/releases), pick a release, such as `1.2.0`, and put it in place of `<version>` below.

* npm

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

* pnpm

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

* Yarn

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

* Bun

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

* mise

  ```shell
  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](/start/install/#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.