Web Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. maintain — this package resolves the question by disqualification. sylius/web-bundle is archived and its own description reads "DEPRECATED — see Sylius/Sylius." There is no adoption decision to make and no vendor relationship to negotiate. The only decision it informs is which Sylius artifact a team should depend on, and the answer is the monorepo, not this repository.
• Framework/platform selection for a commerce roadmap. Evaluated against a Laravel stack, this is a category mismatch, not a close call. It is a Symfony bundle — it hooks into Symfony's bundle registration, DI compiler passes, Twig, and the Sylius resource/Grid/state-machine model. Laravel consumes individual Symfony components, not the Symfony framework, so there is no registration seam. Architecture fit against Laravel is effectively zero.
• Technical-debt triage and upgrade sequencing. If this appears in a composer.json or composer.lock, that is a concrete, dated finding: the codebase predates the consolidation of Sylius' web layer into the main repository. The remediation is a Sylius version upgrade — not a patch, not a fork, not a compatibility shim. Scope it as a prerequisite for any PHP or Symfony minor bump, because an unmaintained bundle is the item most likely to block the upgrade.
• Vendor and dependency-risk register. Archived + deprecated + 13 stars + 0 dependents means no security response, no upstream fixes, and no community support channel. That is a direct entry in a third-party risk register and a straight answer on any procurement or security questionnaire.
• Sizing the real requirement. Most of what "web bundle" connotes — storefront routes, controllers, Twig templates, view helpers — is thin glue over Sylius core. When a stakeholder asks for "the Sylius storefront," the PM job is to separate that thin glue from genuine domain capability, because the glue is a small fraction of the ask and is often reimplementable natively.
• Do not let a dashboard number make this a roadmap item. The automated opportunity: 8.77 sub-score is an artifact of the package's historical Sylius association, not forward-looking value; the composite 0.4925 is the honest signal. Apply an explicit PM override: archived status dominates every other score.

When to Consider This Package

Consider it only in a forensic or audit capacity:

• You are auditing a legacy Sylius installation and need to understand where storefront/admin controllers, routes, and templates originally lived — useful for explaining why a class or route is missing during an upgrade retrospective.
• You are compiling a dependency inventory and need to classify it correctly as deprecated rather than active, so it lands in the migration epic instead of the backlog for "evaluation."
• You are confirming whether a transitive dependency is silently pulling it in, which is a real risk in older lockfiles.

Look elsewhere — or stop — in every other case:

• Any greenfield Laravel build: non-starter. There is no adapter, service provider, or facade. Do not add it to a Laravel composer.json.
• Active maintenance: no maintainer exists. Archived repositories receive no patches, including security patches. Pin-and-pray is not a strategy.
• Feature delivery: anything you believe this bundle provides is available and maintained in sylius/sylius (or the split bundles — sylius/resource-bundle, sylius/grid-bundle, sylius/ui-bundle, sylius/admin-bundle, sylius/shop-bundle). Building here means duplicating work against a dead branch.
• If Sylius functionality is genuinely required on a PHP estate: the only defensible pattern is service isolation — run Sylius/Symfony as a separate deployable and integrate over HTTP APIs, webhooks, or a queue. Keep frameworks in separate processes, repositories, and deploy pipelines.
• If only presentation behavior is required: port the behavior, not the code — Laravel controllers, Blade/Livewire views, Eloquent models — and explicitly reject parity with the bundle's full surface.
• Scoring caution: treat the high opportunity sub-score as a ranking-model artifact. No PM should carry an archived package onto a roadmap because a number looked green.

How to Pitch It (Stakeholders)

For executives: This is a retired internal component of the Sylius e-commerce platform — the presentation layer (controllers, routes, templates) that has since been folded into the main Sylius repository. It is formally deprecated, the repository is archived, it has thirteen stars and zero downstream dependents, and it receives no maintenance or security patches. There is no commercial or strategic case for adopting it, and it cannot run inside our Laravel applications at all — it is built for a different framework's extension model. The only action item is defensive: if it appears anywhere in our stack, budget a migration as part of the next Sylius upgrade rather than carry an unmaintained dependency through a security review.

For engineering: Treat sylius/web-bundle as a redirect, not a dependency — the description itself points to Sylius/Sylius. If it is in a lockfile, the correct remediation is a Sylius version bump that absorbs the web layer into core, not a fork and not a compatibility shim. Do not attempt to load it inside a Laravel process: bundle registration, DI compilation, routing, session, and CSRF semantics do not compose with Laravel's, and you will get autoload collisions and untraceable 404s. If Sylius domain capability is truly needed, isolate it as a separate service behind a small, versioned HTTP/queue contract — and if a fork is somehow unavoidable, vendor it under an internal namespace, pin the commit, assign a named owner, and treat it as first-party code with a review cadence from day one.

Bottom line: no adoption, no investment, no fork in a Laravel context. One line in the risk register, one ticket in the migration epic, and a documented decision so the next team does not rediscover this package and re-open the evaluation.