Quality and review

Two checks, two timings

Two independent gates apply to your packages:

• Package review - a one-time look at the package itself when you first add it: the repository, the name, the pricing model. Some marketplaces run this as an explicit per-package step; others activate packages on creation and rely on the vendor-application review instead. Your operator can tell you which mode this marketplace uses.
• Release checks - automated checks run on every release tag you push. There is no manual review per release.

Where the per-package review applies, release tags you push during that time still go through the automated checks, so when the review completes the package is ready for buyers.

Package review

When you add a package on My packages, a marketplace running with per-package review enabled looks at things like:

• That the composer name matches the name field in your composer.json on a recent tag.
• That the package type is one of magento2-module, magento2-theme, metapackage, or library.
• That the repository is real and accessible, and that the README and CHANGELOG read coherently.
• That at least one tag exists with a parseable composer.json.
• That there is no obvious name conflict or trademark issue against the chosen composer namespace.
• That your pricing model is consistent with the licence declared in composer.json (for example, you cannot sell a GPL-only module without a clear commercial-use grant).

Most reviews clear within a few business days. You receive an email when the review completes, and the package becomes available to buyers. On marketplaces that activate packages on creation, this step does not apply: the same expectations are still on you, but they are enforced after the fact through suspensions and takedowns rather than up front.

Release checks

Every release tag runs through four automated checks. Results appear on the release's page in your dashboard.

Code style

PHP_CodeSniffer with the Magento2 ruleset. Catches Magento-specific anti-patterns and stylistic violations.

Static analysis

PHPStan with the Magento type stubs. Catches null-safety bugs, undefined methods, and type mismatches against your declared dependencies.

Security audit

composer audit against the published advisories list. Surfaces vulnerable dependencies in your release lockfile with their severity, CVE and fix line.

Copy-paste detector

Looks for duplicated code blocks across your codebase.

Each tool reports passed, failed, or pending. A release rolls up to failed if any tool failed, pending while any tool is still running, and passed only when every tool passed.

Whether a failed roll-up actually hides the release from buyers depends on your operator's policy. Some marketplaces serve every release and treat the check results as a quality signal vendors can act on; others hide releases until every check passes. Either way, the per-rule failure detail stays on the release page so you can see exactly what to fix and where.

Where you see results

• Activity feed: a row lands as soon as the checks finish, with the pass or fail outcome. See Activity feed.
• Release page: the Quality tab shows per-tool status, error and warning counts, and the per-rule breakdown for any failures.
• Email: a one-line summary for each release, linking to the release page.

Fix and re-tag

There is no retry button. To ship a fix, push a new semver tag with the corrected code. The new tag runs through the checks afresh. Leave the failed tag in place: the release page keeps an audit record of it. Buyers will only ever see releases that pass.

Reporting a vulnerability

If you find a vulnerability in your own package, another vendor's package, or Packagento itself, report it privately through our contact form. Do not open a public issue or post exploit details. Packagento credits good-faith reports and coordinates patches with affected vendors before publishing advisories.

When you patch a security issue, tag the fix and add a brief, non-exploit-disclosing entry to your CHANGELOG. Buyers see the entry on the release page so they can decide whether to expedite the upgrade.

Troubleshooting

• Package stuck in review for more than a week: Get in touch through our contact form. Most reviews complete within a few business days; a longer delay usually means we have a question we could not reach you with.
• A release is hidden after a check failed: your operator is running the marketplace with check-failed releases hidden from buyers. Ship a corrected release; the new tag runs through the checks afresh.
• Static analysis disagrees with my local run: Packagento runs analysis with the official Magento type stubs. Local installs without those stubs often underreport. Run with the same stubs locally to reproduce.
• Security audit failing on a transitive dependency: bump the affected package in your composer.json require block and re-tag.