Installer Bundle Laravel Package

Technical Evaluation

Architecture fit. sylius/installer-bundle is a first-party Symfony bundle from the Sylius commerce platform, not a framework-agnostic PHP library. It integrates through Symfony's kernel: service definitions and compiler passes in the DI container, routing and Twig templates for the web installer, console commands for the CLI installer, and event subscribers orchestrating the first-run sequence (environment requirement checks → database/schema creation → admin provisioning → fixture/sample-data loading → asset install). Every meaningful collaborator it invokes is a Sylius core service (sylius/resource-bundle, channel/product/order services, Doctrine mappings). Nothing targets Laravel's service container, Artisan, Blade, or Eloquent. For a Laravel team the honest architecture fit is none at the code level; the reusable asset is the pattern — gated prerequisite checks, idempotent and resumable setup steps, one shared service layer behind both a web and a CLI front end.

Integration feasibility. A direct composer require into a Laravel application is not viable. The bundle's dependency graph pulls Symfony component versions that will conflict with those pinned by our Laravel release, and even if resolution succeeded, its registered services reference Sylius services that do not exist in an Illuminate container. The only defensible topology is a separate Sylius runtime with its own Composer root, CI, and database, integrated with our Laravel app only over HTTP/queue boundaries — at which point this is a second platform adoption, not an "integration." There is no middle path worth prototyping.

Technical risk. The dominant risk is a scoping error: a stakeholder sees "PHP package, installer" and assumes it slots into our stack, burning a sprint before the mismatch is proven. Record the rejection explicitly and with rationale so it is not re-proposed. Secondary risks: dependency-hell if anyone attempts in-process use; and metric unreliability — the reported 0 score, blank star count, and 0 dependents are artifacts of Sylius's monorepo split (the bundle reaches users via sylius/sylius), not evidence of abandonment. Do not make a build/buy call on these numbers; verify cadence and support against Packagist download stats and the main Sylius repository. License is MIT, so reading and adapting the source for a native reimplementation is legally clean.

Key questions.

• Are we evaluating Sylius as a commerce platform, or trying to reuse an installer UX for our own Laravel product? These lead to completely different decisions and budgets.
• If the goal is a first-run setup wizard for a Laravel app, why is this package a candidate at all — artisan, laravel/prompts, and a custom app:install command are the native answer?
• Who owns the commerce-platform decision, and would platform ops accept a second PHP/Symfony runtime plus its own database and deploy pipeline?
• What is the verified upstream release cadence and support commitment, read from the Sylius monorepo rather than this read-only split repo?
• Is anyone in the org already running Sylius (agency template, legacy storefront) where the installer is effectively free and already in the box?

Integration Approach

Stack fit. Poor, and this should be written down rather than debated. Our functional equivalents are php artisan migrate --seed, Laravel Prompts for interactive setup, a bespoke app:install command, and Forge/Envoy/Docker for provisioning. A Sylius bundle cannot hook into any of those extension points; its only entry points are Symfony commands and a Symfony-routed web wizard.

Migration path. There is no incremental path from our Laravel codebase to this bundle, and none is needed. Two legitimate paths exist, and the TPM decision is to pick one explicitly:

1. Platform adoption (rare, gated). Stand up Sylius as an independent service — own repo, own lockfile, own CI, own database — and integrate with the Laravel app over HTTP/queue. This is greenfield platform work, not migration, and should be sponsored as such with a named owner and a multi-month horizon.
2. Pattern port (default). Reimplement the installer concept natively: a declarative checklist of requirement gates, idempotent steps with persisted state so a failed run resumes rather than restarts, and both web and CLI front ends over one shared service class. This is days of engineer effort for a Laravel developer and carries zero cross-framework coupling. It preserves the genuine product value of this package — the onboarding UX — without importing the platform.

Compatibility. PHP constraint ranges track Symfony LTS lines and will diverge from the Symfony components pinned by our Laravel version. Keep Composer roots strictly separate; never attempt a shared vendor/. If both ever appear in one CI pipeline, they must be independent jobs with independent lockfiles. Pin any Sylius dependency to a standardized major so upgrades are coordinated rather than incidental.

Sequencing.

1. Intent clarification (1 hour). Decide platform-adoption vs. installer-pattern. This single decision unblocks everything and is the TPM's primary deliverable here.
2. If Sylius is genuinely on the table: timebox a 3–5 day standalone spike on the official Sylius skeleton in a throwaway repo. Success criteria agreed up front: install completes in a container, seeded store renders, deploy story is articulated. Do not touch the product monorepo.
3. If only the pattern is wanted (likely): write a one-page ADR selecting the native Laravel approach, cite this package as the reference design, then prototype app:install with Prompts + migrate --seed.
4. Record the rejection of in-process adoption with rationale, metric caveats, and the MIT-licensed source as a reference, so the question does not recur next quarter.
5. Only after 3–4 land: wire the installer into CI so ephemeral demo/sandbox environments are reproducible.

Operational Impact

Maintenance. Maintained upstream by the Sylius core team, but released as part of the Sylius monorepo — this split repo is a read-only artifact and its version cadence is bound to Sylius majors. Our exposure is therefore zero if we do not adopt, and "whatever Sylius's support policy is, on their timeline" if we do. There is no meaningful custom-code ownership either way; the cost is entirely in platform coupling and upgrade coordination.

Support. Community channels (Sylius Slack, GitHub discussions) with no SLA. Commercial support exists only via Sylius Plus or a certified partner — a real budget line if the installer becomes part of a production-critical deploy pipeline. Bus factor is tied to Sylius the company, not to this repository.

Scaling. Not a runtime concern, and this should be stated plainly to anyone expecting capacity implications. The installer executes once per environment. It has no bearing on request throughput, queue depth, or horizontal scale; in a Sylius deployment the operational cost lives in the application and its database, not here. The only "scale" dimension is environment count — how many demo, sandbox, branch, and per-prospect stores we stand up — which argues for containerizing the install step, not for optimizing it.

Failure modes. If adopted, the realistic failure surface, each of which becomes an on-call incident during a deploy window:

• Partially completed installs leaving a half-migrated database with no clean rollback.
• Requirement checks passing on a developer laptop and failing in a container — var/cache permissions, missing PHP extensions, wrong locale.
• Fixture/sample-data loading timing out on large seeded catalogs.
• Re-running the web installer against a populated environment and duplicating data or clobbering the admin account. These are precisely the reasons installers must be idempotent, resumable, and hard-disabled or removed post-install. If we port the pattern, encode those properties as acceptance criteria; if we adopt the platform, encode them as a deploy gate.

Ramp-up. For a Laravel-only team, productive use of this bundle implies learning Symfony's kernel/DI model plus Sylius's resource and checkout architecture: roughly 2–4 weeks to first meaningful contribution and several months to real depth. That is a platform-adoption cost, not a package-adoption cost, and any proposal citing this repository must price it as such. Ramp-up for the pattern port is effectively zero — a mid-level Laravel engineer can build and ship app:install within a sprint. That asymmetry, more than any technical detail, is the argument the TPM should carry into the decision meeting.