Sensio Distribution Bundle Laravel Package

Technical Evaluation

Architecture fit — fundamentally poor. sensio-distribution-bundle is a Symfony 2/3 Standard Edition artifact. It assumes an AppKernel, a bundles.php-style registration graph, SensioGeneratorBundle peers, and the Symfony console/Composer-script lifecycle (post-install-cmd / post-create-project-cmd). Laravel's extension model — service providers, Artisan, composer.json scripts, the laravel/laravel skeleton — shares none of those primitives. The bundle cannot be loaded by a Laravel application without introducing a second kernel/container alongside Laravel's, which is a dual-bootstrap anti-pattern. The conceptual problem it addresses (scaffolding and validating a "distribution" of a framework) is real; this specific artifact is the wrong framework and the wrong era.

Integration feasibility — low and low-value. A bridge would require autoloading symfony/http-kernel, instantiating a Bundle inside a service provider, and reimplementing the Composer hook contract. Even if that were done, the bundle's actual payload (requirement checks, install-web scaffolding, parameter generation) is either trivially reimplementable in ~50 lines of Composer scripts or already covered by laravel/installer and the skeleton. The effort-to-value ratio is inverted.

Technical risk — high. Last release March 2019; 12 stars; 0 dependents; no active maintenance. The code is written against deprecated Symfony APIs (KernelInterface constants, getParameter-era container access, pre-Flex distribution semantics). There is no disclosure channel and no realistic CVE-response path, so any vulnerability in its dependency surface is effectively permanently unpatched. MIT license is the only clean aspect.

Key questions for the requester. (1) What concrete workflow is being solved — project scaffolding, install-time requirement validation, or distribution packaging? (2) Is a framework-specific answer required, or is a Composer-script + skeleton approach sufficient? (3) For Symfony shops: has this been evaluated against Symfony Flex, which is the direct and maintained successor? (4) If the driver is legacy Symfony 2/3 code, is the real decision "migrate off Standard Edition" rather than "vendor a stale bundle"?

Integration Approach

Stack fit — not applicable to Laravel; superseded on Symfony. On a Laravel stack the correct analogs are laravel/installer, the laravel/laravel skeleton, and composer.json post-create-project-cmd scripts. On a Symfony stack the correct analog is symfony/flex. There is no scenario where adopting this bundle is the shortest path in either ecosystem.

Migration path — none from this package; both directions route around it. For a team currently on Symfony Standard Edition, the migration is Standard Edition → Flex (the officially supported path since 2017), not "keep the distribution bundle and port it forward." For a Laravel team, the migration is any ad-hoc bootstrap toward the standard skeleton plus Composer scripts.

Compatibility — hostile. Runtime constraints target the PHP 5.5–7.x window; it would need re-release and API modernization for PHP 8+, and the deprecated Symfony symbols it depends on are removed in Symfony 6/7. Doctrine, Console, and Filesystem peer constraints all pin to obsolete majors. Expect a multi-day compatibility shim for zero functional gain.

Sequencing.

1. Confirm the actual requirement (scaffolding vs. requirement-checking vs. packaging) — a TPM-level clarification, not an engineering one.
2. If the answer is "project scaffolding," adopt laravel/installer + skeleton + Composer scripts on Laravel, or Flex on Symfony; close the ticket against this package.
3. If the answer is "we are on Symfony Standard Edition," scope that migration separately; this bundle is a casualty of it, not a dependency of it.
4. Only if an explicit, evidenced requirement exists that both Flex and Laravel's installer fail to meet should a fork be considered — and then as an internal, renamed, security-owned package, not as a dependency on sylius-labs/sensio-distribution-bundle.

Operational Impact

Maintenance — unowned. Six years without a release, no active maintainer signal, no dependent packages to inherit fixes. Any adoption implies fork-and-own: CI, PHP version matrix, Symfony API modernization, security triage. That is an ongoing tax on a small team for a non-differentiating capability.

Support — effectively none. No vendor SLA, no issue triage cadence, no security disclosure policy. Slack/Discussion support is unlikely given 12 stars. Escalation path is "we fix it ourselves," which should be priced into the decision.

Scaling — irrelevant at runtime, but the build-time surface matters. The bundle executes during install/bootstrap/console, not per request, so it does not affect production throughput. It does affect every new environment provisioned and every CI job, which is where compounding friction accrues.

Failure modes to expect. Silent non-fatal failures in Composer post-install-cmd hooks; permission errors during install-web / cache warmup; parameter generation that succeeds partially and produces a bootable-but-misconfigured app; requirements checks that pass on PHP 7.2 but are meaningless (or crash) on PHP 8.x. These are deployment-time, environment-specific, and historically hard to diagnose — the worst failure profile for a small team.

Ramp-up — asymmetric and non-transferable. Learning this bundle requires Symfony 2/3 distribution semantics (kernel, bundle registration, Standard Edition layout) that a Laravel team does not have and will not reuse. Even for a Symfony team, the knowledge is anchored to a deprecated model; effort spent here is not portable to Flex. Ramp-up cost is real, the learning dividend is near zero.

TPM recommendation: do not adopt. The package is misaligned with the stated stack, unmaintained, and superseded by first-party tooling in both ecosystems. If a distribution/scaffolding requirement genuinely exists, route it to laravel/installer + Composer scripts (Laravel) or Symfony Flex (Symfony) and record the decision as "framework mismatch — no integration."