Update packages

What happens

03The agent first runs vibe outdated, which compares every pin in the lock file with the newest version the registry offers and prints the difference; it changes nothing. Then it runs vibe update --all. vibe re-resolves the graph, preferring the current version of every package that is not being updated, and fetches what is new into the store. It shows the plan; on confirmation it replaces the package trees, rewrites the lock file and regenerates the boot files. The agent finishes by reading the lock file's diff back to you: that diff is the exact list of text your agent will read differently from now on.

04 vibe update remains the explicit "re-resolve and pick newer" command.

By hand

051. See what is behind:

vibe outdated --path hello-vibe

PACKAGE VERSIONS
GROUP                 NAME                          INSTALLED      LATEST         STATUS
org.vibevm.world      wal                           1.0.0           -               unknown

0 of 1 package have updates available

072. Update one package, or all of them:

vibe update org.vibevm.world/wal --path hello-vibe --assume-yes

Re-resolving 1 package…
  → closure unchanged (1 packages)

Updated 1 package (0 version bumps).

09vibe update --all updates everything in the lock file; the two forms are mutually exclusive.

103. Read the diff of vibe.lock before you commit it. Each changed entry names the old and the new version and fingerprint.

The constraint stays where you put it

11An update moves the pin in the lock file within the constraint the manifest names; it never widens or narrows the constraint. If the manifest says ^1.0, an update will not cross to 2.0 on its own. To move the constraint too, install the new version explicitly with a new constraint, or pass --exact to pin the resolved version in the manifest as well.

12 flow:wal@^0.3 → semver range.

Recovering after a breaking update

13If an update leaves the project in a state that no longer checks, the lock file in version control is your way back. Restore it and run vibe reinstall, which rebuilds the tree from the lock and the store without the network. If the store itself holds a damaged entry, vibe cache check finds it and vibe cache clean --package removes it, after which a fresh install fetches the package again.

14 Without --force it recomputes the materialisation and the boot artifacts from the existing vibe.lock and the local cache — no fresh resolution.

Edge cases and rules

15vibe outdated reads the registries declared in the project's manifest, and for the fastest answer their index; a project created by vibe init declares none, so add one with vibe registry add before asking. Without a network it reports what it could not reach rather than guessing.

16A dependency declared as a git branch is walked again on update and its lock entry moves to the branch's current commit; a tag or a commit stays where it is.

17 Mutable branch. Lockfile records the resolved commit at install time; subsequent vibe update re-walks branch HEAD. Mutable — see "Mutability and vibe update" below.

18--upstream also compares the upstream releases a package declares it describes, for packages that document a third-party library.