Production Dependencies Guard Laravel Package

Product Decisions This Supports

• Dependency hygiene as an enforced standard, not a code-review hope. This plugin turns "dev tooling must go in require-dev" from a wiki page into a hard gate at composer require time. That's a policy decision — do we trust reviewers, or do we automate the rule? — and this package is the cheapest way to pick "automate."
• Build vs. buy for internal guardrails. The alternative is writing and maintaining a custom Composer plugin or a CI lint step that diffs composer.json require sections. At 83 stars and zero dependents, this is a buy/adopt-with-caveats decision, not a strategic platform bet: it's a small, single-purpose tool you can vendor, fork, or replace in an afternoon if it stalls.
• Production artifact and image hygiene. Every dev package wrongly in require ships into production vendor/, inflates container images, widens the CVE surface scanned by security tooling, and pollutes SBOMs. If your roadmap includes slimming deploy artifacts or tightening supply-chain posture, this is a concrete, low-effort contributor.
• Library and SDK publishing quality. If you publish packages to Packagist, your require block becomes your consumers' dependency graph. Shipping PHPUnit or a mocking library as a hard dependency is a product defect in the eyes of downstream users — this package prevents that class of defect at authoring time.
• Monorepo and multi-team contribution policy. In repos where dozens of engineers touch composer.json, the plugin acts as a consistent referee regardless of who reviews the PR, which reduces review load and cross-team nitpicking.
• Onboarding and DevEx roadmap slot. It's a "paved road" item: a five-minute install that signals the platform team cares about dependency correctness, without asking product teams to change their workflows.
• Use cases where it clearly pays off: long-lived Laravel applications, first-party packages consumed by other teams, projects with strict security review, and any codebase where composer.json churn is high.

When to Consider This Package

Adopt when:

• The stack is PHP/Composer and stays that way — this is a Composer plugin, so it's worthless outside that ecosystem.
• You have (or want) a written dependency policy and need an enforcement mechanism that fires at the moment of the mistake, not in a CI postmortem after a release.
• Multiple contributors or teams edit composer.json, or you publish packages externally.
• Your CI already runs composer install; the plugin adds no meaningful runtime or pipeline cost.
• You accept the risk profile: single maintainer, ~83 stars, zero dependents, MIT licensed. That means pin the version, review the source (it's small), and keep a fallback.

Look elsewhere or skip when:

• The team is small and stable enough that review discipline already covers this — you'd be adding a dependency to police dependencies.
• Your organization restricts Composer plugins (allow-plugins policy, hardened CI images) and adding one requires a security review disproportionate to the benefit.
• You need broader dependency governance: unused-dependency detection, layer/architecture rules, or vulnerability blocking. Better fits: composer-unused, roave/security-advisories, Deptrac, or static analysis in CI. This package only answers one narrow question.
• You want a maintained, vendor-backed tool with a support path. There isn't one here.
• Your risk tolerance for transitive tooling is low and a 20-line CI script comparing require against an allow-list would satisfy the same requirement with zero third-party code.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, free, MIT-licensed guardrail that stops development-only libraries from being declared as production dependencies in our PHP services. The business effect is narrow but real: leaner production deployments, a smaller attack surface for security scanners, and cleaner software bills of materials — enforced automatically instead of relying on reviewer vigilance. Cost is a few minutes of setup, there is no runtime overhead, and it can be removed as easily as it's added. The caveat worth stating plainly is that it's a single-maintainer open-source project with modest adoption, so we should pin it, keep it out of any critical path, and treat it as a hygiene measure rather than a security control.

To engineering: It's a Composer plugin that intercepts composer require and refuses packages that belong in require-dev, with an override for legitimate exceptions. Install is a single dev dependency plus a plugin allow-list entry; behavior is deterministic and fast, so it belongs in local dev and CI alike. Expect occasional false positives on unusual package metadata — budget a short tuning window and document the escape hatch in the contributing guide. Because upstream activity is thin, we should pin an exact version, read the source (it's small), and keep a fallback CI check ready so a stale dependency never becomes a blocker. Treat the decision as reversible: the exit cost is an afternoon, which is what makes it a safe experiment.