Glossary

Use this glossary to look up terms in the command pages. Entries are alphabetical.

LPM CLI is the local lpm executable. LPM.dev Registry hosts packages and distribution services. LPM Firewall provides package verdicts and npm policy checks. LPM CLI works with npm and other registries, as well as LPM.dev Registry.

Add (vs. install)

lpm add copies package source into your project. lpm install installs runtime dependencies into node_modules, or installs Swift dependencies through the supported Swift workflow. The commands are separate operations.

Auto-build

Automatic dependency lifecycle execution after installation. An explicit --auto-build, project scripts.autoBuild, or effective allow policy can request it. It also runs when all packages with pending scripts are trusted, including applicable triage approvals.

Each package must still pass the applicable execution gates. scripts.denyAll suppresses execution. See Lifecycle scripts.

Behavioral tag

A label for behavior found by static package analysis, such as network access, shell execution, or dynamic code evaluation. A tag is evidence for review, rather than proof that a package is malicious. Use lpm audit and lpm query.

Capability

A dependency script's request for access or resource limits beyond its baseline. The lpm.scripts fields include passEnv, readProject, sandboxReadAllow, sandboxWriteDirs, and sandboxLimits.

A request that widens the baseline needs a matching approval. Equal or tighter limits do not require that extra approval. See lpm approve-scripts.

Cold install

An install without reusable installed packages or cached package contents. Remote packages need retrieval; local sources remain local. See lpm install.

Config-aware package

A source package with lpm.config.json at the archive root. lpm add uses this file for prompts, conditional files, and dependency changes. See lpm.config.json.

Distribution mode

A package's access and payment model on LPM.dev Registry: Private, Free, Pool, or Marketplace. Private is the default. The publisher selects other modes explicitly. See LPM.dev package distribution.

Greedy-fusion (resolver)

The default dependency resolver. It selects package versions and their dependency graph. LPM_RESOLVER=pubgrub selects the alternative resolver. See Resolver.

Hoisted layout

A node_modules layout that exposes root direct dependencies at the project root and keeps package-local links in shared store entries. It is the starting default for standalone projects.

Workspaces default to isolated layout. Unconfigured installs also switch to isolated layout when peer requirements conflict. See lpm install for explicit linker settings.

Importer

One project's record in a lockfile. It contains manifest inputs and, in a workspace, that project's selected package graph. The root importer is .; members use relative paths. See Lockfile format.

Integrity

A content hash that binds expected package archive bytes, commonly an SRI value such as sha512-…. Downloaded archives are checked when expected integrity is available; validated cached state can be reused. Without a registry hash, permissive installs record a hash on first retrieval. --strict-integrity rejects that missing hash.

A mismatch is an error. Mutable directory and link sources use manifest fingerprints instead of archive integrity. See Lockfile format.

Isolated layout

A node_modules layout that gives each package links to its declared dependencies. It is the default for workspaces and for automatic recovery from incompatible peer requirements. See Content-addressable store.

Lockfile

The authoritative lpm.lock TOML file. It records exact package instances, sources, dependency targets, and workspace selections. Current schema 13 has no binary companion. See Lockfile format.

LPM home

The directory for data that isn't part of any project: user configuration, login state, local env secrets, the package store, caches, and global packages. It is ~/.lpm by default, or the directory that LPM_HOME names. See Files LPM CLI creates.

lpm.dev

The hosted LPM.dev Registry, including package access, distribution, and monetization services. LPM CLI is registry-agnostic. See Registries.

Marketplace package

An LPM.dev Registry distribution mode with paid package access through a license purchase. The publisher opts in per package. See LPM.dev package distribution.

MCP

Model Context Protocol, a protocol that connects AI tools to external capabilities. Use lpm mcp setup to configure supported editor integrations.

Minimum release age

A waiting period before newly published package versions become eligible for installation. It is off by default. Direct scope checks direct dependencies; strict scope also checks transitive dependencies and lockfile replay.

--allow-new requests a one-run bypass, subject to applicable security authorization. See lpm install, lpm trust, and lpm config for duration and exclusion settings.

npm-alias dep

A dependency with a local name that differs from its canonical package name, such as "my-react": "npm:react@^19.0.0". The lockfile preserves the alias and its exact selected target. See npm compatibility.

Package instance

One exact package in a resolved graph, including its dependency and peer targets. Two instances can share the same name, version, and archive but use different targets. See Lockfile format.

Plugin

A managed tool that LPM CLI downloads and verifies for a built-in command. Examples include Oxlint for lpm lint, Biome for lpm fmt, and Rolldown for lpm bundle.

lpm check uses an installed tsc by default, preferring the project version and then checking system PATH. --engine tsgo uses a managed plugin. lpm pack uses project-installed tsdown. Pin supported tools in lpm.json; manage cached versions with lpm plugin.

Pool package

An LPM.dev Registry distribution mode with public metadata and subscriber-gated installation. Eligible usage contributes to the publisher's share of Pool revenue. See LPM.dev package distribution.

Project state (.lpm/)

The .lpm/ directory in a project. It holds machine-local state, such as install checkpoints, certificates, tunnel captures, and env sync state. It ignores itself through .lpm/.gitignore, so Git never sees it. Committed LPM CLI files use lpm.* and lpm-* names at the project root instead. See Files LPM CLI creates.

Provenance

Signed evidence that links a package artifact to its build or publisher identity. lpm publish --provenance can attach supported publication evidence.

Install verification depends on the configured scope and availability policy. Frozen replay checks recorded evidence against the lockfile without re-verifying the original bundle. lpm audit signatures checks registry signatures, which are a separate mechanism. See Security audit.

Provenance drift

A change from an approved provenance reference: removal of provenance, publisher changes, workflow-path changes, or a different Git reference kind. A new tag value alone does not count as drift.

Comparison needs an approval reference and available current evidence. Best-effort availability does not promise a comparison during every install. See lpm approve-scripts and Security audit.

Quality score

A package score from 0 to 100 based on metadata and package-quality signals. Use lpm quality to inspect it or lpm publish --min-score to set a publishing threshold.

Rebuild

Dependency lifecycle execution through lpm rebuild. The dependency phases are preinstall, install, and postinstall, in that order. Dependency prepare and prepublishOnly are detected but are not executed by this step.

Untrusted dependency scripts are blocked by default. Approved scripts can run through rebuild or auto-build. Root-project install hooks use a separate lifecycle.

Standalone rebuild targets the project. For a global package, use lpm approve-scripts --global, then reinstall the package.

Sandbox

Operating-system containment for dependency lifecycle scripts. The normal modes are default, strict, and none. The effective protection depends on the platform, authorized configuration, and any explicitly permitted degraded mode.

Configure it through invocation flags, project lpm.toml, or user config.toml. A request for weaker protection can require a security unlock. Root-project lifecycle hooks use the ordinary script runner. See Security and Policy.

Save policy

The rule that selects the dependency range written to package.json after installation. The default is ^<resolved-version>. See Save policy.

Script policy

The dependency lifecycle policy: deny by default, or explicitly authorized allow or triage. It does not govern the root project's install hooks.

The requested policy follows CLI, project, user, then default precedence. Global installs omit the project tier. Security authorization and managed floors also apply. See Lifecycle scripts.

Skill (agent skill)

Instructions that help an AI agent use a package or workflow. A package author keeps skills in lpm-skills/. Installing the package places them under .lpm/skills/<package>/ in the consuming project, which stays local. lpm skills also manages standalone sources; a project records them in lpm-agent-skills.json.

These two sources have different installation and validation rules. See AI agent skills.

Source package

A package whose files are delivered into a project through lpm add. It can be a plain source copy or a config-aware package. The package name or registry alone does not determine the installation behavior. The committed lpm-sources.json records what each delivery copied.

Store

The shared package store in the LPM home, normally ~/.lpm/store/. The default v2 layout keeps canonical package objects and graph-specific link entries. Experimental v3 adds shared file blobs and tree manifests.

Writable package files use independent clones or copies, so project writes do not alter canonical contents. Use lpm store; see Content-addressable store.

Triage advisor

An optional advisor for dependency scripts under the triage policy. Available choices are none, claude-cli, codex, and ollama. Configure it per project or user, or override it with --advisor for an install.

Advisor approvals apply to the current run and are not saved for future runs. See Security audit.

Trusted dependency

A dependency permitted to pass the trust gate for lifecycle execution. Trust can come from an explicit binding or an approved scope pattern. Artifact and script changes, requested capabilities, and security policy can still prevent execution.

Project trust lives in package.json > lpm > trustedDependencies. Global trust lives in ~/.lpm/global/trusted-dependencies.json. Both rich binding formats can record provenanceAtApproval. Use lpm approve-scripts to review blocked packages.

Tunnel claim

A reservation for a stable tunnel domain on LPM.dev Registry, available to eligible Pro and organization accounts. See Tunneling.

Up-to-date install

An install that reuses recorded installation state because the relevant inputs and checks still match. Admission and policy checks still apply; reuse does not mean no work occurs. See lpm install.

Warm install

An install that can reuse a valid lockfile and cached package contents, often to restore missing node_modules. Missing packages, stale inputs, policy checks, or --force can require extra work or network requests. See lpm install.

Workspace

A group of packages declared through package.json > workspaces, pnpm-workspace.yaml, or both. LPM CLI supports the manifest array form and object form with a packages array.

--filter selects members. For install, -w selects the workspace root. See Workspaces.