Composer Parser Laravel Package

Technical Evaluation

Architecture fit. Framework-agnostic value-object layer over composer.json — it turns a raw manifest into typed objects (package, authors, autoload, require/require-dev, scripts, support). It is not a Laravel package: no service provider, no facade, no config, no publishable assets. In a Laravel app it belongs as an infrastructure adapter behind a port (ManifestReader interface), not as a direct dependency smeared across controllers and jobs.

Integration feasibility. Pure PHP, MIT, no extensions, no daemons. Installability is the gating item: the last release is September 2019, so the require block likely caps at PHP ^7.x. Verify before anything else — a Laravel 10/11/12 host is PHP 8.1+, and a constraint mismatch forces a fork on day one rather than day ninety. Audit the transitive tree (likely composer/semver and possibly justinrainbow/json-schema) for conflicts with what Laravel's installer and dev tooling already lock.

Technical risk.

• Abandonment: 7 stars, 0 dependents, no commits in ~6 years, single maintainer. There is no security-patch channel and no schema-maintenance channel.
• Schema drift: the Composer manifest schema has moved since 2019 — config.allow-plugins, funding, archive, newer autoload types, platform require entries, and expanded extra conventions. A 2019 parser may silently drop unknown keys, which produces wrong data rather than an error — the worst failure mode for a reporting use case.
• Coercion edge cases: license as string vs array, authors as object vs list, inline stability flags and aliases in constraints (dev-main as 1.0.0), branch-alias. Confirm these are parsed or passed through raw.
• Untrusted input: safe only if you parse manifests already inside your repo or your own vendor tree. If ingesting third-party manifests, bound JSON depth/size and treat every field as hostile.
• Value delta: json_decode covers ~80% of the surface. The package earns its keep only when typed access is needed across multiple call sites.

Key questions for the spike.

1. What is the exact PHP constraint, and does it install clean on 8.2/8.3?
2. Does it validate against the Composer schema or merely decode and map?
3. Does it preserve unknown keys, or expose a raw-array escape hatch?
4. Does it return constraint strings verbatim, or attempt semver interpretation?
5. Who owns the fork if we need one, and where does it live?

Integration Approach

Stack fit. Laravel 9–12, PHP 8.1+. Zero framework coupling in either direction. Bind ManifestReader → ComposerParserManifestReader in a dedicated service provider; keep the vendor class out of application code entirely so the swap cost stays at one file.

Migration path.

1. composer require the pinned release, inspect the lock diff for transitive surprises.
2. If the PHP constraint blocks, fork to internal/composer-parser on org VCS, widen the constraint, add a PHPUnit matrix (8.1/8.2/8.3 × Laravel current).
3. Wrap in the interface; add parity tests against a corpus of real manifests.
4. Long-term, plan replacement with composer/composer's ArrayLoader plus composer/semver, or a thin in-house decoder. The wrapper makes this a single-file change.

Compatibility. Primary collision surface is composer/semver and any symfony/* pins — both are already present transitively in most Laravel installs. Check composer why on both before committing.

Sequencing.

• Spike (0.5 day): install, parse three manifests — laravel/framework, a monorepo with path repositories, and one deliberately exotic file.
• Harden (1–2 days): fork if needed, add the interface and adapter, write the parity fixtures.
• Ship one bounded use case: a read-only artisan command or admin dashboard panel (license inventory, dependency health, upgrade planning). Do not let it into the request path.
• Decide (next major): retain fork vs replace. Set a calendar trigger.

Operational Impact

Maintenance. Self-maintained from day one, regardless of intent. Code volume is small (value objects and a mapper), so a fork is bounded work — but it must be registered in an at-risk/vendored inventory with a named owner and a periodic review cadence. The decision record matters more than the code.

Support. No upstream, no CVE feed, no issue triage. Escalation is your own engineers. Document that explicitly so future maintainers do not assume Composer ecosystem coverage.

Scaling. CPU cost is negligible; cost lives in I/O and in breadth. Scanning hundreds of vendor manifests on every request will hurt — cache parsed results keyed by file hash or mtime, and move bulk scans to a queued job that persists normalized rows. Per-manifest memory is small but unbounded on input size; cap file size defensively.

Failure modes.

• Malformed JSON → catch and surface a typed failure, never a 500.
• Unknown/newer schema keys → silent data loss. Assert on this in the parity tests; it is the failure that reaches users as a wrong license or missing author.
• Package's own type hints breaking on a PHP upgrade → pin and test.
• Constraint strings fed into naive version comparison → keep them as opaque strings unless composer/semver is doing the work.
• Transitive conflict surfacing only at composer update time → resolve at install, not at upgrade.

Ramp-up. Low. The API is a small set of getters over ComposerJson and nested objects; a mid-level engineer is productive in under a day. The real work is the interface, the fixtures, and the fork governance — not learning the library.

Recommendation. Adopt narrowly, behind an interface, forked if the PHP constraint demands it, and treat it as a stopgap with a scheduled exit. For a single call site, skip it and use json_decode plus composer/semver directly.