lpm upgrade

Upgrade direct dependencies in the current project, then update its manifest, lockfile, and installed packages.

lpm upgrade [OPTIONS] [PACKAGE]...

Quickstart

lpm upgrade react --dry-run --json
lpm upgrade react -y

The first command previews the upgrade. The second applies it without a prompt.

--json also selects non-interactive mode. The CI environment variable alone does not disable the menu.

There is no upgrade block in lpm.json. Dependency declarations and upgrade-related configuration belong in package.json.

Examples

# Select upgrades in a terminal
lpm upgrade

# Upgrade two direct dependencies without a prompt
lpm upgrade react react-dom -y

# Preview major upgrades
lpm upgrade react react-dom -y --major --dry-run

# Apply major upgrades
lpm upgrade react react-dom -y --major

# Upgrade a dependency in one workspace member
cd packages/web
lpm upgrade react -y

To inspect available versions without applying changes, use lpm outdated.

Upgrade an alias

Given this declaration:

{
  "dependencies": {
    "strip-ansi-cjs": "npm:strip-ansi@^6.0.0"
  }
}

Target the local name:

lpm upgrade strip-ansi-cjs -y

LPM CLI preserves the local name and the npm: alias syntax.

Which packages are eligible?

LPM CLI works with npm, the LPM.dev Registry, and private registries. Upgrade uses recorded package sources to select safe metadata routes.

It checks dependencies, devDependencies, and optionalDependencies in the nearest package.json at or above the current directory, as lpm install does. From a subdirectory, it prints the directory it chose. It does not select transitive dependencies or standalone peer declarations.

Optional declarations take precedence over runtime and development declarations. Runtime declarations take precedence over conflicting development declarations. Identical runtime and development declarations update together.

Eligible sources are:

• Packages named @lpm.dev/*.
• npm packages that lpm.lock records as public npm or configured LPM.dev Registry proxy installs.

An untargeted run skips packages without eligible source records. An explicitly requested package without eligible source records causes an error.

Local paths, Git sources, tarballs, workspace references, JSR references, and catalog references are not upgrade targets. An untargeted run skips them.

For a catalog dependency, edit the owning catalog, then run lpm install. Upgrade never replaces a catalog: reference with a version.

Version selection

Without --major, simple exact, caret, and tilde declarations advance within the current numeric major version. This can exceed the original declared range.

Complex ranges retain their text and select a version within that range. Stored tags, such as latest or next, retain their text and follow that tag. A missing tag causes an error.

--major selects the eligible latest version for version-range declarations. It preserves an exact, caret, or tilde prefix. Other version-range forms become an exact version.

Version-range selection does not pass the current latest tag. A maintainer rollback therefore limits the upgrade target, even if greater versions remain published.

Upgrade does not downgrade an installed package. Named tags can select a newer major or prerelease version without --major.

Selected packages use the versions from the preview. Other direct registry dependencies retain compatible locked versions. New dependencies and incompatible manifest changes still require resolution. Transitive dependencies can change.

Upgrade preserves the declaration style described here. It does not use the save policy for new dependencies.

Configuration

Upgrade uses the project's minimum release age policy:

{
  "lpm": {
    "minimumReleaseAge": 86400,
    "minimumReleaseAgeExclude": ["@my-org/*"],
    "minimumReleaseAgePolicy": "strict"
  }
}

minimumReleaseAge is a duration in seconds. minimumReleaseAgeExclude exempts matching package names. minimumReleaseAgePolicy: "strict" also checks transitive dependencies during installation.

When the latest release is too recent, version-range selection uses an eligible release at or below the current latest tag. Upgrade has no one-run release-age override flag.

Package overrides also apply. Upgrade omits a proposed target when an override controls that target. Installation still applies the normal engine, peer, registry, and security policies.

Read the preview

The menu and JSON output include three signals:

The menu shows major upgrades as separate rows. If you select two targets for the same declaration, the higher version wins.

Use -y --major for a batch major upgrade. --major is incompatible with interactive mode.

Project files and scripts

A successful upgrade updates package.json, lpm.lock, and node_modules. Current installs use the TOML-only schema.

In a workspace member, upgrade updates that member's part of the shared root lockfile. Sibling members keep their lockfile records.

The root project's install lifecycle runs around installation. Dependency lifecycle scripts remain subject to the normal approval policy. Upgrade has no --auto-build flag.

Use lpm approve-scripts and lpm rebuild for dependency scripts. In JSON mode, root script output goes to stderr.

Recover from an error

If a public dependency lacks a recorded source, refresh the project first:

lpm install
lpm upgrade react -y --dry-run

If a stored tag no longer exists, correct its declaration before another upgrade.

A malformed lockfile, metadata error, or concurrent manifest edit stops the upgrade. Installation failure restores the saved manifest and lockfiles, while preserving detected concurrent edits.

Rollback does not undo arbitrary lifecycle script effects. A failed installation can also change node_modules. After correcting the error, run lpm install.

Automation and JSON

lpm upgrade react -y --dry-run --json > upgrade-plan.json
lpm upgrade react -y --json > upgrade-result.json

A preview and a later apply are separate invocations. Each invocation revalidates metadata and builds its own plan.

Successful JSON includes success, dry_run, upgraded, packages, and fetch_errors. On a preview, upgraded counts proposed declaration updates.

Each package row includes name, from, to, new_range, is_dev, semver_class, has_install_scripts, peer_impact, and patch_invalidation. Optional dependency rows also include is_optional.

Skipped packages appear in skipped_private or skipped_non_registry when applicable. A successful result with no candidates has upgraded: 0 and an empty packages array.

An error produces success: false and a nonzero exit status. Upgrade does not apply a partial plan after a metadata lookup failure.

Flags

See the global flags for shared options.

See also

• lpm outdated — compare installed and available versions.
• lpm install — apply manual dependency or catalog changes.
• lpm add — add a dependency or request a specific version.
• Patches — maintain local package changes.