Package types

LPM.dev Registry supports two author-facing classifications: dependency packages and source packages. Authors can select the Registry classification with the optional lpm.config.json > type field. When type is omitted, LPM.dev Registry keeps its content-based inference.

Registry classification	Typical consumer command	What happens
Dependency package	lpm install	LPM CLI adds and manages a JavaScript or Swift dependency when no source-delivery config is present
Source package	lpm add	LPM CLI copies selected source files into the consumer's project

Classification and LPM CLI delivery behavior are related but distinct. Any valid lpm.config.json activates the configured lpm add path, even when "type": "package" classifies the package as a dependency package in LPM.dev Registry.

Dependency packages

Dependency packages are versioned libraries managed by a package resolver. They are the normal choice when consumers should import the package and receive updates without owning its source files.

lpm install @lpm.dev/acme.my-library

For JavaScript, LPM CLI installs the dependency into the project's managed package layout and records it in package.json.

For Swift, LPM CLI uses LPM.dev Registry's Swift Package Registry service, updates Package.swift or the Xcode project integration, and lets SPM resolve the package.

See the LPM CLI install reference for resolver behavior, save policy, workspaces, and every flag.

Source packages

Source packages deliver files that become part of the consumer's codebase:

lpm add @lpm.dev/acme.login-form

LPM CLI identifies a version as config-aware source delivery when its published package contains either:

• A valid lpm.config.json.
• A valid package.json > lpm.source path.

lpm.config.json can describe file-copy rules, interactive options, conditional dependencies, and import rewriting. A simple lpm.source path marks the source directory without adding the richer configuration surface. The optional type field controls the LPM.dev Registry classification only; it does not make LPM CLI ignore the rest of the config.

After delivery, the consumer owns the copied files and can modify them. Updating the Registry package does not automatically update those local copies.

See Source Code Delivery for the user workflow, Source Configuration for the authoring model, and the LPM CLI add reference for full command behavior.

Ecosystem is separate

JavaScript and Swift describe the package ecosystem. Dependency and source describe how package contents reach a project. They are independent dimensions.

For Swift libraries, use the dependency model and lpm install so SPM manages versions and transitive dependencies. Source delivery is for files that consumers intentionally take ownership of and edit.

Distribution is separate

Both delivery models can remain private or use the reviewed Pool and Marketplace distribution paths. Choosing source delivery does not make a package public, and choosing a dependency package does not determine its price or audience.

See Distribution Modes for access and monetization.

Choose a delivery model

Use a dependency package when:

• Consumers should import it as a versioned library.
• Updates and transitive dependencies should be resolver-managed.
• The implementation should remain encapsulated.

Use a source package when:

• Consumers are expected to edit the delivered files.
• The package is a component, template, starter, or reference implementation.
• Installation needs project-specific file selection or configuration.

See also

• Packages — Package naming, ecosystems, collections, and distribution.
• Source Code Delivery — How consumers use lpm add.
• Source Configuration — Author source-delivery behavior with lpm.config.json.
• Swift Package Registry — Install Swift dependencies through SPM.