Plugins Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow — decision: do not adopt, optionally borrow the design. This is an archived Symfony2 bundle (14 stars, zero dependents, no maintainer, EOL runtime from 2018). The only defensible "leverage" for a PM is prior-art review of its plugin manifest, discovery conventions, and enable/disable lifecycle — not shipping the dependency.
• Feature scoping — clarify the requirement before committing engineering time. Ask whether the underlying need is “let third parties extend our product” versus “let our own team toggle features/modules.” Only the former justifies a plugin-install abstraction; the latter is a feature-flag/config problem and a far cheaper build than a plugin ecosystem.
• Roadmap positioning — Laravel roadmap is unaffected. The bundle is not a Laravel package and cannot be installed into Laravel 10/11 on PHP 8.2+ without hard Composer conflicts. Any roadmap item framed as “integrate Sylius plugins” should be re-framed as “define our own plugin extensibility spec.”
• Architecture investment — fund a small internal spec, not an integration. A 1–2 day timeboxed read of the archived source to extract the plugin contract (manifest schema, discovery rules, installed/enabled/disabled/update-available states) yields a reusable internal design doc. Reimplementation as a native Laravel package is days, not weeks, and produces something we own.
• Product use cases worth naming: third-party extension marketplaces, modular enterprise deployments with togglable feature packs, and legacy Symfony2/Sylius audits during acquisition due diligence or migration inventory.
• Investment decision — zero integration budget. Do not spike against this package unless a specific legacy Sylius migration requires understanding its historical behavior. Otherwise redirect the effort into maintained alternatives: Laravel-native package discovery (extra.laravel.providers), Composer plugins, or a maintained modular package framework.
• Security posture as a product commitment. A plugin-install path is a code-execution boundary. If we pursue extensibility, we are implicitly signing up for signature verification, allowlists, sandboxing, rollback, and a version-compatibility matrix. An archived bundle offers none of that and should not be the reference for these decisions.

When to Consider This Package

• Only when maintaining, auditing, or migrating a legacy Symfony2 application that already ships this bundle (or Sylius plugins) in its composer.json.
• During acquisition or migration due diligence on an inherited Sylius codebase, to identify historical plugin-registration and discovery behavior before planning the replacement.
• For a short, isolated prior-art read (1–2 days max) to extract the plugin lifecycle and manifest design — with an explicit no-production-dependency rule attached to the timebox.
• When the question is “how did Symfony2/Sylius historically register and toggle plugins?” and the deliverable is a written internal spec, not code.
• Look elsewhere — for Laravel: use Laravel service providers with Composer package auto-discovery, a plugins state table, or a maintained modular package framework. None of these map to Symfony bundles.
• Look elsewhere — when support matters: no maintainer, no security advisories, no release cadence. Disqualifying for anything touching production, especially a plugin install/execute path.
• Avoid entirely if: you require PHP 8.1+, Laravel 9+, vendor backing, long-term patching, or any supply-chain assurance. All of these apply here.
• Red flags during discovery: any transitive dependency that drags the package into a lockfile, any runtime that “phones home” to a plugin registry endpoint, and any proposal to fork the bundle internally “just to get it working.”

How to Pitch It (Stakeholders)

Executives — one line: This is an archived Symfony2-era plugin bundle with negligible adoption and zero dependents; it is not a Laravel package, it is not on any roadmap, and it should not enter our budget. Adopting it would create permanent unpatched maintenance and security exposure. If plugin extensibility is a product priority, fund a short discovery effort to define our own contract — and build it natively.

Executives — what we get for the effort: a 1–2 day prior-art review that produces an internal plugin-extensibility spec. That spec is the actual asset. The bundle is a reference document, not a dependency.

Engineering — framing: treat this as prior-art review, not dependency adoption. It is a Symfony2 bundle registered in AppKernel with a DI container, YAML/XML service loading, and PHP 5.x–7.0-era constraints — none of which exist in Laravel. Composer resolution will fail before runtime; forcing it with --ignore-platform-reqs gives undefined behavior against PHP 8, not “mostly working.”

Engineering — the extraction plan:

1. Confirm the underlying requirement (third-party extensibility vs. internal configurability). Only the former needs an installable-plugin model.
2. Timebox a 1–2 day read of SyliusPluginsBundle.php, DependencyInjection/, and the plugin manager service. Document the manifest schema, discovery rules, and lifecycle states as an internal spec.
3. Decision gate: build a native Laravel package vs. adopt a maintained modular framework vs. drop the requirement.
4. If building: Composer-based discovery, a plugins table for state, a PluginServiceProvider, and no third-party plugin distribution until a signing/verification model exists.
5. Never add this package to any composer.json at any stage.

Engineering — the risks to state explicitly:

• Silent transitive pull into the lockfile — installs, never patched, invisible until an advisory lands, and none will.
• Dead plugin registry endpoint — listing/install fails opaquely with no upstream to triage.
• Partial extraction — porting fragments imports Sylius-shaped assumptions (Doctrine resources, container parameters) that resurface as confusing runtime errors.
• Fork drift — an internal fork diverges permanently from a dead upstream with no rebase path.
• Security boundary erosion — remote plugin fetch/execute without signature verification is the last trade-off to accept from an archived codebase.

What we will not do: integrate it, vendor it, fork it into production, or let a Sylius constraint leak into the Laravel roadmap. If a real Symfony/Sylius product exists elsewhere in the portfolio, isolate this evaluation to that product and flag it for migration planning.