Package identity

A package request is not an identity. acme-widget@^2.4 describes a name and a version range, but it does not identify the code that a project will install.

Follow one request to one artifact

A useful package decision binds the request to all of these values:

TermWhat it answersExample
Package nameWhich package did the request name?acme-widget
Version rangeWhich releases are acceptable?^2.4
Resolved releaseWhich exact version was selected?2.7.1
Registry identityWhich registry object supplied it?npmjs.org/acme-widget
Artifact digestWhich exact bytes will be used?sha512-...
Lockfile entryWhat must a later operation reproduce?tapid.lock record

The range is a constraint. The resolved release is a selection. The artifact digest identifies the bytes. The registry identity prevents the same name and version from silently referring to different registry objects.

Why the lockfile matters

A later offline or frozen operation should not resolve the request again. It should validate the lockfile's manifest digest, package identities, tree digests, and verified store content before activating managed node_modules.

That behavior is implemented for the current replay path. The client prints:

Replayed lockfile: 0 package(s)

The fixture used for this check contains an empty package set, so the output is not an example of a populated dependency graph. It is evidence that the replay path validated and activated the fixture project.

What is implemented and what is planned

The current CLI has lockfile validation and deterministic replay. It does not yet provide the complete package identity and evidence view described by the product direction. Registry-wide publisher provenance, independent artifact verification, private-registry routing, and policy decisions remain planned or incomplete.

Read Evidence and policy to see how an exact identity would feed a decision, then return to Getting started for the supported replay command and current status.