Updating & Pinning

Updating to latest

If a pack is configured as latest in iconforge.json, rerunning the install command pulls the most recent published release:

npx @icon-forge/cli install acme/brand/core-icons

The CLI resolves the latest release, downloads it, and replaces the tracked files.

Pinning a release

To lock a pack to an exact version, install it by release hash:

npx @icon-forge/cli install acme/brand/core-icons --version 8f3a9c2d14be

This saves the pin in iconforge.json:

{
  "packs": {
    "acme/brand/core-icons": "hash:8f3a9c2d14be"
  }
}

From that point, install uses the pinned version until you change it.

Unpinning

Edit iconforge.json and change the pack entry back to "latest", then rerun install:

{
  "packs": {
    "acme/brand/core-icons": "latest"
  }
}

Preview with dry run

See what would happen without writing anything:

npx @icon-forge/cli install acme/brand/core-icons --dry-run

Shows the resolved release, output path, component list, and any conflicts.

Reinstall behavior

The CLI does a deterministic reinstall every time — it doesn’t skip unchanged files. Even if the resolved release is the same, the CLI re-downloads and rewrites the tracked files and refreshes the lockfile.

Conflict flags

Flag	Result
`--force`	Overwrite unrelated conflicting files
`--skip`	Leave conflicts alone, install only safe files
`--dry-run`	Preview the plan without touching disk
(default)	Error with a clear conflict message

Tracked files from a previous install are always replaced — that’s a reinstall, not a conflict.

When to pin

Pin when:

Your team depends on a known-good icon set and doesn’t want surprise changes
You’re in the middle of a UI refactor and need a stable baseline
You need reproducible builds for a release branch

Stay on latest when:

The app should track the pack as it evolves
The design team ships small fixes regularly and you want them automatically