Installer Bundle Laravel Package

Product Decisions This Supports

• Time-to-first-value for anything Sylius-based. This bundle owns the "first run" moment: environment validation, database creation, schema build, admin account bootstrap, sample catalog loading, and asset pull — via one umbrella sylius:install command or a browser wizard. If we ship a commerce product where activation means "get a working demo store running," this is the front door that decision depends on.
• Build vs. buy on onboarding. A setup wizard plus fixture seeding is commodity engineering. Adopting the upstream, core-maintained installer is almost always cheaper than owning a bespoke bootstrap flow — that budget is better spent on differentiated commerce features (pricing, checkout, fulfillment) rather than a check-requirements screen.
• Distribution and packaging strategy. If we ship a Sylius distribution — a branded storefront, a vertical starter kit, an agency template — the installer is part of our product surface. "Clone, run, demo store in minutes" is a real developer-experience and sales-engineering differentiator, and it is a make-or-break signal for evaluators.
• Self-serve provisioning roadmap input. Web wizard plus CLI parity gives two adoption paths: CLI for CI, containers, and power users; web for demos and less technical evaluators. That split is exactly the roadmap question "do we invest in self-serve merchant onboarding, or keep provisioning assisted?"
• Demo and sandbox operations. Repeatable installs with seeded sample data make per-prospect and per-branch demo environments practical — a lever for sales engineering and QA.
• What this does not support: a Laravel decision. This is a first-party Symfony bundle from Sylius, not a framework-agnostic PHP library. It has no relationship to Artisan, Blade, Eloquent, or Laravel's container. If the decision in front of us is "how do we improve onboarding in our Laravel app," this package is not an input — the native answer is php artisan migrate --seed, Laravel Prompts, and a small app:install command. The transferable asset is the pattern (gated prerequisite checks, idempotent resumable steps, shared service layer behind web and CLI front-ends), not the code.

When to Consider This Package

• Sylius is already the substrate. The only coherent adoption path. In practice the bundle ships with sylius/sylius, so it is present by default rather than deliberately added — we would be configuring and extending it, not evaluating it cold.
• Bootstrap is non-trivial and repeatable. Consider it when a first install genuinely needs environment checks, database wiring, admin creation, fixture loading, and asset pulling — and we want that standardized rather than a pile of ad-hoc scripts.
• We distribute a Sylius-based product. Agencies and vendors shipping templates, starter kits, or vertical distributions extract the most value; the installer is part of the out-of-box experience users judge us on.
• Web and CLI parity matters. If both interactive demos and automated pipelines are real use cases, upstream maintaining both paths beats us maintaining two homegrown scripts.
• Look elsewhere when:
  • The stack is Laravel. Composer resolution will collide with the Symfony component versions our Laravel release pins, and even if it succeeded, the registered services reference Sylius services that do not exist in an Illuminate container. The only defensible topology is a separate Sylius service with its own Composer root — at which point it is a second platform, not an integration.
  • It would run in production. This is a setup-time tool. Plan to disable or remove it post-install; do not treat it as a provisioning or security boundary.
  • We need real infrastructure provisioning — that is IaC, containers, and CI pipelines, not a PHP bundle.
  • We need multi-tenant SaaS onboarding with billing, org management, and tenant isolation. Build that ourselves.
  • We want long-term API stability. The bundle tracks Sylius majors; upgrades and platform versions must move together.
• Do not read the vanity metrics. The reported 0 score, blank stars, and 0 dependents are artifacts of Sylius's monorepo split workflow — this repo is a read-only mirror of a component users receive via sylius/sylius. Any build/buy call must be verified against the main Sylius repository and Packagist download stats. License is MIT, so reading and adapting the source is legally clean.

How to Pitch It (Stakeholders)

To executives: This is a small, upstream-maintained component that shortens the path from "interested" to "working demo." It reduces the custom code we own for setup, lowers onboarding support tickets, and makes it cheap to stand up seeded demo or sandbox stores for sales and partners. Cost is low and the maintenance burden sits largely with the Sylius core team. The caveat is strategic rather than technical: it only pays off if Sylius remains our commerce platform. It is a commitment to that ecosystem, not a standalone bet — and if the underlying question is "can we use this in our Laravel product," the answer is no, and we should say so early rather than after a sprint of discovery.

To engineering: It's the official Sylius installer, delivered as a Symfony bundle with both a web wizard and console commands (sylius:install umbrella plus check-requirements, database, sample-data, setup, assets as standalone steps). It handles environment validation, database configuration, admin bootstrap, fixture loading, and asset pull through Symfony's DI and console conventions, and InstallerEvents is the extension point if we need to inject custom provisioning. Two things to plan for: treat it strictly as an install-time concern — disable or remove it in production — and pin it to whatever Sylius version we standardize on so upgrades are coordinated rather than incidental. Also budget the real cost honestly: for a Laravel-only team, productive use means learning Symfony's kernel/DI model and Sylius's resource and checkout architecture — roughly 2–4 weeks to a first meaningful contribution. That is a platform-adoption cost, not a package-adoption cost.

To sales/solutions: It gives us a credible "minutes, not days" demo story and a repeatable way to generate seeded storefronts per prospect or per branch — evaluators poke at a realistic catalog instead of an empty shell.

Recommended next step: Clarify intent in one hour — are we evaluating Sylius as a platform, or trying to borrow an installer UX for our own product? If the former, timebox a 3–5 day standalone spike on the official Sylius skeleton in a throwaway repo. If the latter, write a one-page ADR choosing the native Laravel approach and explicitly record the rejection of this package with rationale, so it is not re-proposed next quarter.