Dependencies
The LPM.dev Registry stores package metadata, applies rules for public distribution, and authorizes each package download. It does not resolve your dependency graph: the LPM CLI resolves JavaScript dependencies, while Swift Package Manager resolves Swift dependencies.
JavaScript dependency metadata
The LPM.dev Registry currently handles these package.json fields:
| Field | Stored | Purpose |
|---|---|---|
dependencies | Yes | Runtime dependencies |
devDependencies | Yes | Development-only dependencies |
peerDependencies | Yes | Dependencies supplied by the consuming project |
bundleDependencies / bundledDependencies | Yes | Package names declared as bundled; both aliases and the array or boolean form are accepted |
optionalDependencies | Yes | Optional runtime dependencies |
peerDependenciesMeta | Yes | Peer optionality and related metadata |
Registry metadata preserves these fields from the validated package manifest.
For installation behavior, version selection, peer dependencies, and lockfiles, see the LPM CLI install reference and Resolver.
Free dependency rules
Every identified LPM.dev Registry dependency must resolve to an available Free release. Private, Pool, Marketplace, missing, and unavailable versions prevent Free admission. This includes development, optional, and peer declarations, aliases, bundled copies, nested manifests, source configuration, and shrinkwrap records.
Public npm dependencies are outside LPM.dev Registry access rules. They still undergo publication security review. A URL or alias cannot disguise a restricted LPM.dev Registry dependency as an external package. Unsupported or incomplete dependency analysis keeps the release unavailable.
Quarantine blocks the affected dependency and known releases containing its bytes. An ordinary dependency declaration does not automatically quarantine the parent archive. Operators can inspect affected ordinary dependents separately.
Pool and Marketplace dependency rules
Pool and Marketplace publication adds rules for direct dependencies hosted by the LPM.dev Registry:
| Direct dependency | Marketplace release | Pool release |
|---|---|---|
Canonical @lpm.dev/owner.package name missing from the Registry | Blocked | Blocked |
| Private LPM.dev Registry package in any inspected field | Blocked | Blocked |
| Pool package in any inspected field | Allowed | Allowed |
Unbundled Marketplace package in dependencies | Blocked; use a peer for separate purchase or a verified bundle | Blocked |
Unbundled Marketplace package in peerDependencies | Allowed without a publisher Commercial License; each consumer needs separate access | Blocked |
Unbundled Marketplace package in devDependencies | Cross-owner use requires a publisher Commercial License; same-owner use is allowed | Blocked |
| Verified Marketplace bundle from another owner | Requires a publisher Commercial License | Blocked |
| Verified Marketplace bundle from the same owner | Allowed without a self-purchase | Blocked |
| Public package from npm or another registry | Outside LPM.dev Registry entitlement rules | Outside LPM.dev Registry entitlement rules |
A verified bundle takes precedence when the same package also appears in a dependency field. Without a bundle, duplicate declarations use deterministic precedence: dependencies, then peerDependencies, then devDependencies. The Registry verifies declared LPM.dev bundles against the uploaded archive rather than trusting manifest metadata alone: it parses each bounded nested package.json at the expected package path and requires its name to match the bundle declaration exactly.
These checks govern whether a package can be distributed through Pool or Marketplace. They are separate from dependency resolution and installation.
Private parent packages are not subject to these public-distribution dependency gates.
Each archive requires access
Access to a parent package does not grant access to its dependencies. When installation selects an archive hosted by the LPM.dev Registry, the Registry authorizes that package and version independently.
For example, access to a Marketplace package does not automatically grant access to an unbundled Marketplace peer. The consumer must also have the entitlement required for that dependency. Bundled code is delivered inside the parent archive instead; it does not grant the consumer a separate entitlement to the bundled package.
Swift dependencies
Swift dependencies are declared in Package.swift and resolved by Swift Package Manager. Every selected archive hosted by the LPM.dev Registry still receives its own entitlement check when downloaded.
Free admission also validates inspected Swift dependency declarations. Unsupported or incomplete Swift dependency analysis prevents Free admission. See Swift Package Registry for publishing and installation details.
