Quality Score

The LPM.dev Registry stores a quality report for each published version. The report scores observable package signals out of 100 and shows authors and consumers where a package is well prepared or could improve.

A quality score is not a security verdict and does not approve a Pool or Marketplace release.

Score tiers

Tier	Score
Excellent	90–100
Good	70–89
Fair	50–69
Needs Work	0–49

Local and Registry scoring

Quality scoring has two stages.

Before upload

The LPM CLI builds the prospective package archive and reports the checks it can perform locally:

lpm publish --check

Use --min-score when a local score should block the publication command:

lpm publish --min-score 60

The threshold applies to the local report, before upload. Checks that require Registry data cannot earn points at this stage, so the local result can be lower than the final stored score.

See the LPM CLI quality reference and publishing reference for command behavior and output.

During Registry publication

The LPM.dev Registry independently verifies the submitted report against the uploaded archive and Registry data. Verification includes package metadata, included files, source signals, known vulnerabilities, publication history, publisher profile, and package-published Agent Skills.

The verified report is stored with the version. The package page and lpm quality show the report for the latest version available to that caller.

Score categories

JavaScript and Swift packages use separate 100-point rubrics:

Ecosystem	Documentation	Code quality	Testing	Package health
JavaScript	22	29	11	38
Swift	22	31	11	36

Documentation

Documentation checks look for a substantive README, installation guidance, usage examples, API or reference material, a changelog, and license metadata.

JavaScript code quality

JavaScript signals include type declarations, ESM and exports metadata, tree-shaking support, engine requirements, dependency footprint, source maps, IntelliSense coverage, and dynamic-code patterns.

Swift code quality

Swift signals include declared platforms, Swift tools version, multi-platform support, public API, DocC comments, and dependency footprint.

Testing

Testing checks look for test files or Swift test targets and a usable test configuration.

Package health

Health signals include description and discovery metadata, repository and homepage links, package size, known vulnerabilities, semantic-version history, publisher verification, maintenance recency, and package-published Agent Skills. JavaScript scoring also checks install and uninstall lifecycle scripts.

Security review is separate

Some score signals overlap with security concerns, such as known vulnerabilities, lifecycle scripts, and dynamic code. They still do not replace publication review.

Private versions do not require public-distribution review. Every Pool and Marketplace version must pass that review before consumers can access it, regardless of its quality score.

Maintenance age

Publishing a version satisfies the maintenance-health check. Once the displayed version is more than 90 days old, the LPM.dev Registry marks that check as failed and removes its full point value from the displayed score.

The score does not decline a little each day. A new publication starts with a newly computed report.

AI analysis is separate

After a public version passes publication review, the LPM.dev Registry can generate summaries, capabilities, compatibility fields, and other AI metadata. That enrichment helps package pages and discovery, but it does not contribute to the quality score.

Inspect a published report with the LPM CLI:

lpm quality @lpm.dev/acme.ui-kit