Technical Evaluation

Architecture fit

drupol/composer-packages is not a Laravel library — it is a Composer plugin that hooks Composer's own runtime and registers a packages command (plus a small PHP API) for enumerating installed packages by Composer "type" (library, composer-plugin, drupal-module, custom installer types, etc.) with table and JSON output.
Fit for a Laravel codebase is therefore at the tooling/CI layer, not the application layer. Its capability overlaps heavily with composer show --format=json and composer licenses --format=json.
The only genuinely differentiated capability is filtering by package type — relevant only if the project installs non-library artifacts (Drupal/WordPress/Magento/custom installer types) and needs a single inventory command.
If the underlying need is a runtime Package::all() inside a Laravel app, this is the wrong shape: it pulls Composer internals into the application's autoload graph.

Integration feasibility

Low effort to trial: composer require --dev drupol/composer-packages, add an entry to config.allow-plugins (Composer 2.2+), then run composer packages.
The plugin API constraint is the crux. A 2020-era release was built against Composer 1.x/early 2.x and PHP 7.x; modern stacks (PHP 8.2/8.3, Composer 2.6/2.7) are untested by the maintainer and may trip plugin-API or deprecation errors.
Because plugin resolution happens before the app boots, a mismatch fails at install time, not at feature use — the highest possible blast radius for a low-value tool.

Technical risk

Abandonment: last release 2020-10-24, single maintainer, 32 stars, low health score. No security response path, no PHP 8.x guarantees.
Dependency weight: the PHP API mode requires composer/composer in the autoload graph — a large, privileged dependency to avoid in production Laravel images.
Commodity overlap: Composer ships the same data via composer show; maintained SBOM plugins (CycloneDX) cover the audit angle. Unique value is narrow.
Supply chain: a Composer plugin executes code on every Composer invocation in any repo where it is allowed — a privileged position for an unmaintained package.

Key questions

What decision does this output feed — SBOM, license audit, CI gate, or a runtime feature? Only tooling use justifies a plugin.
Do we actually install non-library package types, or is composer show --format=json sufficient?
What are our pinned PHP and Composer versions, and has the plugin been smoke-tested there?
Are we willing to own an internal fork if the maintainer is inactive?
Who consumes the JSON, and is the schema stable enough to depend on?
Is allow-plugins governance in place, and can approval be scoped to dev-only?

Integration Approach

Stack fit

Treat strictly as a developer/CI tool: require-dev, repository root, never in the application's require block, never in production images.
Do not adopt the PHP API (PackagesCollection and related classes) inside Laravel service providers or Artisan commands. Read composer.lock or vendor/composer/installed.json directly instead — zero new dependencies.

Migration path

Phase 1 (≈1 day): on a throwaway branch, install the plugin against the real PHP/Composer matrix, run composer packages and composer packages --format=json, and diff against composer show --format=json.
Phase 2: if the diff adds nothing, drop the package and standardize on built-in Composer commands wrapped in a composer inventory script.
Phase 3: only if type filtering is genuinely load-bearing, adopt as a pinned dev dependency with a documented allow-plugins entry and a --no-plugins CI fallback.
Phase 4: if it proves necessary but unmaintained, fork into an internal namespace pinned to a commit — never float on dev-master.

Compatibility

Validate against the exact PHP/Composer versions in CI images; assume the 2020 release does not support later Composer plugin-API changes without testing.
Laravel version is effectively irrelevant — the plugin is framework-agnostic and does not touch the framework lifecycle.
Watch allow-plugins: unapproved plugins hard-fail Composer 2.2+. Document approval in the repo and keep it out of global Composer config.

Sequencing

Confirm the use case and the downstream consumer of the output.
Smoke-test on the real version matrix (PHP 8.2/8.3, Composer 2.6/2.7).
Compare output parity with composer show / composer licenses.
Decide in order of preference: built-in commands → internal script → pinned plugin → internal fork.
If adopted, wire into a single CI job, not onto developer machines broadly.

Maintenance

Effectively unmaintained. Budget for owning it: an internal fork, or a documented decision to tolerate breakage. Every Composer minor/major upgrade reopens the risk.
The allow-plugins entry becomes permanent repo configuration requiring review on each Composer upgrade.

Support

GitHub issues only; no SLA and no maintainer activity evident since 2020. Internal teams become first-line support.
Documentation is thin; expect tribal knowledge around flags and JSON shape. Mitigate by wrapping the command in a composer script or Makefile target with a documented output contract.

Scaling

Runtime cost is negligible — enumeration is in-memory over installed.json, fine for hundreds of packages and for CI matrix fan-out.
The scaling concern is organizational: once approved in allow-plugins, the plugin loads on every Composer command in that repo, so one breakage stalls all installs and CI for the team.

Failure modes

Plugin/Composer API mismatch → hard failure on composer install, blocking builds and deploys. Highest severity; mitigate with dev-only install plus a --no-plugins fallback job.
PHP version bump (8.1/8.2/8.3) → deprecation warnings or fatals inside Composer's process.
Output schema drift across versions → brittle downstream parsing; pin the version and validate JSON in the consuming script.
Missing plugin approval on a fresh clone → confusing empty or failed inventory job.
Supply chain: unmaintained plugin code executing with Composer's privileges is an audit finding waiting to happen.

Ramp-up

Low technical ramp-up — one command, a few flags, table or JSON output; a mid-level engineer is productive in under an hour.
Higher decision ramp-up: ownership and fallback strategy must be agreed before adoption, because reversing course after it lands in allow-plugins touches every repo.
Recommendation: no production dependency. Trial it, benchmark against composer show --format=json and a maintained SBOM plugin, and default to built-ins unless type-based filtering is a hard requirement.