Sensio Distribution Bundle Laravel Package

Product Decisions This Supports

• Legacy lifecycle decisions, not new capability. This is the SyliusLabs maintenance fork of sensio/distribution-bundle — the bundle that registers the sensio:distribution-bundle:composer script handlers used by Symfony 2.x/3.x-era distributions (the old framework-standard-edition-style skeletons). The only genuine product question it answers is: "how long do we keep our pre-Flex Symfony skeletons alive, and who owns the shim while we do?"
• Roadmap sequencing for a Flex migration. If any part of the portfolio still ships a composer create-project distribution, this package is a marker on the migration burn-down chart. Its presence in a composer.json is a reliable signal that a repo is on the old distribution model and is a candidate for symfony/flex + symfony/runtime.
• Build vs. buy vs. delete. "Buy" is a 30-second edit (MIT, drop-in, no transitive footprint); "build" is ~20 lines of Composer scripts; "delete" is the correct answer for anything on Symfony 4+. Framing it as a buy decision will produce a false sense of economy — the cost is not acquisition, it's the unbounded tail of owning an abandoned dependency.
• Use cases it legitimately supports: keeping Sylius plugin test applications and CI harnesses running on the same pins Sylius itself uses; reproducing upstream behavior in a fork where the upstream is unmaintained; archiving a working build for a product line in maintenance-only mode.
• Decisions it explicitly does not support: greenfield Symfony scaffolding, plugin/app distribution for Symfony 4+, asset installation or cache warming (that's Flex recipes plus assets:install / cache:clear in CI), or anything requiring a security-response commitment.

When to Consider This Package

Adopt only when all of the following hold:

• You maintain a Symfony 3.x-or-earlier distribution skeleton that already depends on the upstream sensio/distribution-bundle, and upstream is no longer viable for you.
• You specifically want the Sylius-pinned fork — i.e., you are inside the Sylius plugin ecosystem and need version alignment with Sylius' own test applications, where a divergent fork would cause resolution conflicts.
• You want a minimal-diff drop-in with zero new behavior, because rewriting Composer hooks is out of scope for the current cycle.
• The repo is in maintenance, with an owner and an exit date, not on a growth path.

Look elsewhere — or simply remove it — when:

• Anything on Symfony 4/5/6/7. Distribution bundles were superseded by Symfony Flex in 2017. There is no migration path forward; there is only removal.
• You just need post-install/post-update hooks. Plain Composer scripts cover this without a bundle, a kernel registration, or a dependency.
• You need support guarantees. 12 stars, 0 dependents, last release 2019-03-04. No upstream, no CVE path, no bus factor beyond one, and effectively no community to triage an issue. That is disqualifying for any product with a support obligation or a customer-facing SLA.
• You are evaluating it as a dependency for a new service. With zero dependents there is no ecosystem evidence of fitness; absence of adoption is the finding, not a gap in the data.
• You need the modern equivalent. symfony/flex, symfony/runtime, and recipe-driven config are the replacement; there is no feature of this package that Flex does not obsolete.

How to Pitch It (Stakeholders)

For executives — one line: this is a deprecated Symfony bootstrap shim that we should not adopt, and should actively remove where it already exists; the cheaper-looking option is the more expensive one over any horizon longer than a quarter.

The ask: no budget to adopt; a small, bounded budget to exit. Replacing it is a per-repo task measured in hours — delete the bundle, move Composer hooks into scripts, let Flex own the skeleton. The cost is proportional to the number of legacy skeletons still shipping, and it is the kind of work that only gets more expensive with time.

Why "free" is the wrong frame: the license is MIT and the install is trivial, which makes it look like a saving. The actual liability is structural — last release March 2019, 12 stars, 0 dependents, single-maintainer fork of an already-abandoned upstream. There is no security-response path. Every quarter it stays in a supported product, we are accepting unpatched-dependency risk in exchange for deferring a few hours of work.

For engineering — the honest read: it exists because Sylius needed it for its own plugin test apps, not because it has independent value. If we're not in that exact position, it's not for us. If we are, pin it, document the exit condition, and put a date on the migration to Flex rather than treating the fork as a stable foundation.

Recommendation: Do not adopt. Remove on sight from Symfony 4+ repos. For remaining legacy distributions, treat as a time-boxed compatibility shim with a named owner and a Flex migration ticket.