Composer Require Checker Shim Laravel Package

Product Decisions This Supports

• Dependency governance and CI gating. composer-require-checker (upstream maglnet/composer-require-checker) statically verifies that every symbol your code uses at runtime is backed by a declared Composer requirement. As a PM this supports the decision "do we enforce a hard gate in CI that blocks merges introducing undeclared/implicit dependencies?" — a policy decision with a clear blast radius (fewer production Class not found incidents after a transitive dependency drops a package in a patch release).
• Supply-chain and upgrade readiness. The signal feeds release planning: before a framework or PHP minor upgrade, running the checker tells you whether your dependency surface is actually declared or accidentally inherited. That converts "we think it'll be fine" into a measurable check.
• Build vs. buy vs. shim. This repo is itself the artifact of that decision — someone chose not to fork the tool and not to wait for an upstream fix, but to publish a thin shim. It is a useful precedent when your team debates "pin, patch, fork, or shim" for a blocked dev dependency.
• Framework-agnostic scope check. Note for roadmap framing: despite being requested as a Laravel/PHP package, this is Composer tooling, not application code. It belongs in the engineering platform / developer experience bucket, not the product feature backlog. It ships no runtime code and has no user-facing surface.
• Adoption signal as a decision input. Zero stars, zero dependents, and hosting on an internal IRSTEA GitLab means this is almost certainly a single-organization workaround, not a community-supported component. That is a legitimate negative input to a "standardize our toolchain" decision.

When to Consider This Package

Consider it only when all of the following hold:

1. You already want composer-require-checker in CI (undeclared-dependency detection is a real pain point for you, typically after an incident).
2. Installing the upstream package fails or conflicts in your environment — the usual reasons being a pinned PHP version, a locked Symfony Console/composer-plugin-api constraint, or a private Packagist mirror that cannot resolve upstream's requirements. A shim exists precisely to absorb that incompatibility; if upstream installs cleanly, the shim adds nothing.
3. You can read and vet the shim's composer.json in a few minutes — it should be a constraint-relaxing wrapper, not a vendored copy of upstream code.
4. You accept the maintenance burden of tracking upstream releases yourself.

Look elsewhere when:

• Upstream maglnet/composer-require-checker installs without conflict — depend on it directly and skip the shim entirely.
• You want a maintained, community-vetted tool with an issue tracker and release cadence. Zero stars and zero dependents means no external users are finding or fixing its bugs.
• Your actual need is unused dependencies rather than undeclared ones (composer-unused), or broader static analysis (PHPStan, Psalm) that catches the same class of defect with more coverage.
• You need a supported commercial dependency — this has no vendor, no SLA, and an internal-only URL that may disappear or change access policy.
• Your team cannot self-host or mirror a GitLab repository as a Composer VCS source.

Also treat the low score as a vetting trigger, not a verdict: for a 50-line constraint shim, low popularity is expected and not disqualifying — but it does mean you are the maintainer of record.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free developer tooling component that lets us automatically catch a specific class of production bug — code that works in development because a library happens to be installed indirectly, then breaks in production when that library is upgraded or removed. Cost is near zero and it runs in CI, not in the product. The caveat is that the specific repository in front of us is an internal, single-organization workaround with no external users, so we should adopt the practice (dependency verification in CI) as standard, and treat this particular package as an implementation detail our platform team owns and can replace in an afternoon if it goes stale.

For engineering leads: The upstream tool is maglnet/composer-require-checker; this repo is a shim that relaxes install constraints so it can be pulled into our environment. Recommendation: evaluate upstream first; adopt the shim only if a concrete version conflict blocks us. Budget an hour to diff its composer.json against upstream, pin it, mirror it internally, and add a note to our dependency-upgrade runbook so it does not silently rot. It is not Laravel-specific — place it in the platform/DevEx toolchain, not the application dependency set, and keep it in require-dev.