Module Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for module/plugin extensibility. This package is market evidence that "install a module via Composer and have the app register it automatically" is a durable, recurring requirement — one Laravel now ships natively (extra.laravel.providers + php artisan package:discover). The buy decision is already made for us by the framework; there is nothing to procure.
• Requirements input for a plugin/module architecture. If we are scoping third-party extensibility (white-label deployments, an add-on marketplace, per-tenant feature modules), this package gives us a free, battle-scarce checklist of the hard parts: opt-in metadata contract, deterministic registration order, cache invalidation on install/remove, rollback on failed install, and no manual kernel edits.
• Reference design, not a dependency. Reading the source is a cheap way to enumerate edge cases for our own spec. That is the only budget line this package justifies — a spike, not a delivery item.
• A framing correction worth acting on. Despite being tagged Laravel/PHP, this is a Symfony 2/3 bundle targeting AppKernel::registerBundles(). It maps to zero production code paths in a Laravel codebase. Flagging that early prevents a wasted evaluation cycle and sets the precedent that "Laravel/PHP" tags on package registries are not a reliable filter.

When to Consider This Package

Adoption criteria — effectively none are met:

• You maintain a legacy Symfony 2/3 application with a hand-edited AppKernel.php and cannot adopt Symfony Flex (which supersedes this package and is core-team maintained).
• You want to read the implementation as a reference for your own module registrar.

Look elsewhere — i.e., do not adopt — because:

• Abandoned and read-only. Archived, last release 2016-06-13, 0 stars, 0 dependents. No maintainer, no security response, no PHP 8 compatibility, no test signal, no fork-and-patch path you would want to own permanently.
• It mutates source code at install time (a Composer hook rewrites AppKernel.php). That breaks reproducible builds, immutable containers, CI layer caching, and code review. Modern equivalents use declarative composer.json extra metadata plus a generated manifest artifact.
• Framework mismatch. Symfony-specific by design; irrelevant to a Laravel stack.
• Boot-time blast radius. Failure modes are boot-time fatals with no graceful degradation — health checks go red, whole app down — plus cold-start divergence from autoloader ordering and stale container/OPcache state after deploys.

Preferred alternatives:

• Laravel: native package discovery; for internal modules, a generated module manifest at deploy time or a service-provider registry keyed off config/modules.php.
• Symfony: Flex recipes, or Kernel::registerBundles() reading a config array.
• If you need runtime toggling rather than install-time registration, use feature flags (Pennant or a hosted flag service) instead of build-time injection.

How to Pitch It (Stakeholders)

Executives: The idea — "install a module with Composer and the app picks it up automatically" — is sound, and every modern framework now ships it for free. This specific package is a 2016, archived, zero-adoption implementation written for Symfony, not Laravel. Recommendation: do not add it as a dependency; adopt the pattern natively. No procurement, no license cost, no migration, no support contract. The win here is confirming the underlying requirement and pointing it at the native mechanism — which removes a dependency rather than adding an unmaintained one.

Engineering: Treat it as a case study, not a dependency. Laravel already implements this in PackageManifest; Symfony implements it in Flex. If we build a module system, the constraints this package surfaces — opt-in metadata in each module's own composer.json, deterministic registration order, cache invalidation on install/remove, rollback on failed install, and no source mutation — are the constraints we must satisfy, but with declarative metadata and a generated manifest rather than rewriting kernel files at install time.

Risk statement: Archived, 0 dependents, last release 2016 — there is no patching path and no security triage. Adopting it would create unsupported-code and audit findings for negligible benefit, and its boot-time hook means the first symptom of a problem is a fully unavailable application.