vix outdated checks whether project dependencies are behind the latest versions available in the local Vix Registry index.

Use it when you want to inspect dependency updates without changing your project files.

vix outdated

vix outdated compares the versions pinned in:

vix.lock

with the latest versions known by the local registry index.

It does not update anything. It does not install anything. It does not rewrite vix.json. It does not rewrite vix.lock. It only reports dependency status.

Use it before deciding whether to run:

vix update

vix outdated
vix outdated [@]namespace/name
vix outdated [@]namespace/name [@]namespace/name
vix outdated [options]

# Check all locked dependencies
vix outdated

# Check one dependency
vix outdated gk/jwt

# Scoped-style syntax is accepted
vix outdated @gk/jwt

# Check several dependencies
vix outdated gk/jwt gk/pdf

# Machine-readable output
vix outdated --json

# Strict mode for CI
vix outdated --strict

vix outdated performs this flow:

read vix.lock
read local registry index
collect locked dependencies
read latest registry version for each dependency
compare locked version with latest version
print current, latest, and status

The comparison is based on locked dependencies, not dependency ranges.

That means the source of truth is:

vix.lock

not:

vix.json

vix outdated needs the local registry index.

If the registry is not synced, Vix reports:

registry not synced
Run: vix registry sync

Fix it with:

vix registry sync
vix outdated

vix outdated reads:

vix.lock

If the file is missing, the command fails.

Typical fix:

vix registry sync
vix add gk/json@^1.0.0
vix install
vix outdated

or:

vix update
vix outdated

Run:

vix outdated

Vix checks every dependency listed in:

vix.lock

Example output shape:

Outdated
Package   Current  Latest  Status
gk/json   1.0.0    1.1.0   outdated
gk/jwt    1.2.0    1.2.0   current

✔ checked 2 package(s), outdated 1

Run:

vix outdated gk/jwt

The package must exist in vix.lock.

If it does not, Vix reports:

dependency not found in vix.lock: gk/jwt

This is intentional.

vix outdated checks project dependencies.

It does not check arbitrary registry packages unless they are locked by the current project.

Run:

vix outdated gk/jwt gk/pdf

Vix checks only those dependencies.

Each dependency must exist in vix.lock.

Both forms are accepted:

vix outdated gk/jwt
vix outdated @gk/jwt

Both refer to:

gk/jwt

Version suffixes are parsed, but outdated status is still based on the version pinned in vix.lock.

Example:

vix outdated @gk/jwt@1.x.x

This still checks the locked dependency:

gk/jwt

The default output is a table.

Columns:

If a dependency exists in vix.lock but cannot be found in the local registry index, Vix marks it as:

missing

Example:

Package   Current  Latest  Status
gk/json   1.0.0    -       missing

Then it prints a warning:

1 package(s) missing from local registry index

Common fix:

vix registry sync
vix outdated

If it is still missing after sync, the package may not exist in the registry index anymore or the lockfile may point to an old package id.

Use:

vix outdated --json

Example output shape:

{
  "command": "outdated",
  "packages": [
    {
      "spec": "gk/json",
      "id": "gk/json",
      "current": "1.0.0",
      "latest": "1.1.0",
      "outdated": true,
      "found_in_registry": true
    },
    {
      "spec": "gk/jwt",
      "id": "gk/jwt",
      "current": "1.2.0",
      "latest": "1.2.0",
      "outdated": false,
      "found_in_registry": true
    }
  ]
}

Use JSON output for:

• CI
• scripts
• dashboards
• maintenance reports
• dependency monitoring

vix outdated gk/json gk/jwt --json

The spec field keeps the user-provided package spec.

The id field is the normalized dependency id.

Use:

vix outdated --strict

Strict mode changes the exit code.

This is useful in CI when you want stale dependencies to fail a maintenance job.

You can combine strict mode with JSON:

vix outdated --json --strict

This prints machine-readable output and still returns 1 if any dependency is outdated or missing.

Without --strict, outdated dependencies do not make the command fail.

Vix reads the latest version from the local registry entry.

It first checks:

latest

If that field is not available, it reads all available versions and selects the latest semver version.

That means the result depends on the local registry index.

Refresh it with:

vix registry sync

vix outdated does not resolve version ranges.

It compares:

current locked version

against:

latest registry version

So if your vix.json says:

{
  "deps": ["gk/json@^1.0.0"]
}

and your vix.lock pins:

gk/json 1.0.0

while the registry latest is:

1.1.0

vix outdated reports:

outdated

It does not decide whether the range allows the update.

Use:

vix update

to resolve and rewrite the lockfile.

Use vix outdated to inspect.

Use vix update to change the project.

vix install is for reproducible installation.

vix outdated is for dependency maintenance visibility.

A good maintenance workflow is:

vix registry sync
vix outdated

Check current state:

vix registry sync
vix outdated

If something is outdated:

vix update
vix install
vix build --build-target all
vix tests

Or, when supported by your update workflow:

vix update --install
vix build --build-target all
vix tests

A CI job that only reports dependency status:

vix registry sync
vix outdated --json

A CI job that fails when dependencies are stale:

vix registry sync
vix outdated --strict

A CI job that produces JSON and fails when stale:

vix registry sync
vix outdated --json --strict

vix outdated

vix registry sync
vix outdated

vix outdated gk/jwt

vix outdated gk/jwt gk/pdf

vix outdated @gk/jwt

vix outdated --json

vix outdated --strict

vix outdated --json --strict

vix registry sync
vix outdated
vix update
vix install

Wrong expectation:

vix outdated should update vix.lock

Correct model:

vix outdated only reports status

To update:

vix update
vix install

If results look old, refresh the registry:

vix registry sync
vix outdated

vix outdated needs locked project dependencies.

If vix.lock is missing, first add or update dependencies:

vix add gk/json@^1.0.0
vix install

Wrong:

vix outdated gk/unknown

if gk/unknown is not in vix.lock.

Correct:

vix add gk/unknown
vix install
vix outdated gk/unknown

vix outdated compares locked version to registry latest.

It does not resolve ranges.

Use:

vix update

when you want version resolution.

missing means the package was not found in the local registry index.

It does not necessarily mean the package is missing from .vix/deps.

Run:

vix registry sync

then check again.

Run:

vix registry sync

Then:

vix outdated

Create or update the lockfile:

vix add gk/json@^1.0.0
vix install

or:

vix update

Valid package specs look like:

namespace/name
@namespace/name
namespace/name@version
@namespace/name@version

Example:

vix outdated gk/jwt
vix outdated @gk/jwt@1.x.x

Invalid:

vix outdated jwt
vix outdated gk
vix outdated @/jwt

If Vix reports:

dependency not found in vix.lock: gk/jwt

the current project does not have that dependency pinned.

Check all dependencies:

vix list

or inspect:

vix.lock

Then add the dependency if needed:

vix add gk/jwt
vix install

Run:

vix registry sync
vix outdated

If it is still missing, the package may not exist in the current registry index.

If the project has no dependencies, JSON output is:

{
  "command": "outdated",
  "packages": []
}

This is valid.

Run vix registry sync before dependency maintenance checks.

Use vix outdated before updating dependencies.

Use vix outdated --json for reports.

Use vix outdated --strict in CI only when you intentionally want stale dependencies to fail the job.

Commit vix.lock.

Do not manually edit vix.lock.

Use vix update to refresh locked versions.

Use vix install after updating the lockfile.

Run tests after updating dependencies.

Update dependency versions intentionally.

Open the vix update guide