Channel Bundle Laravel Package

Product Decisions This Supports

• Multichannel scoping and requirements definition. Gives the product team a concrete vocabulary for channel-level configuration — per-channel locales, currencies, tax zones, catalog visibility, payment and shipping methods — so requirements can be written against a proven domain model instead of invented from scratch. This is the bundle's real PM value: a reference blueprint, not a dependency.
• Build vs. buy for commerce platform selection. Informs the central decision of whether to adopt Sylius as the multichannel backbone or reimplement channel semantics in-house. The bundle itself is integration glue inside a platform, so it should feed a platform decision, not a library decision.
• Roadmap risk and dependency hygiene. With 3 stars, 0 dependents, and read-only split status, this must not appear as an independently maintained dependency on any roadmap. Any plan that assumes separate maintenance, a community, or an issue tracker is misinformed.
• Feature prioritization for a Laravel product. Directly supports the question "do we need genuine multi-channel operation, or multi-storefront presentation?" — divergent pricing, tax, payment, and catalog per channel is a materially larger scope than localized storefronts, and the channel abstraction clarifies that line.
• Platform and ecosystem evaluation input. Useful where channel isolation and per-channel configuration are core requirements and the org is evaluating Symfony/Sylius-based commerce.
• Explicitly not a Laravel roadmap input. This is a Sylius/Symfony bundle with no service provider, no config publishing, and no Eloquent surface. It should be excluded from build-vs-buy options for a Laravel-based product unless we are evaluating Sylius itself.

When to Consider This Package

• Consider it when the organization is already on Sylius or committed to the Symfony/Sylius ecosystem and needs to understand or extend native multichannel channel integration. There, the correct move is to require the platform (sylius/sylius) and let this arrive transitively — never a direct Composer requirement.
• Consider it when running a formal Sylius platform evaluation and you need evidence of how channels, per-channel locale/currency, channel-scoped pricing, and catalog visibility actually work.
• Consider it as a design reference — even in a Laravel shop — for channel resolution by hostname/request context, per-channel defaults, and channel-scoped pricing and cart/order partitioning. The domain concepts transfer in days; the code does not.
• Look elsewhere when the application is Laravel-based, non-Symfony, or needs a lightweight standalone channel-management library. Fit is effectively zero.
• Look elsewhere when you need a heavily adopted, independently maintained package with broad ecosystem support. Low stars and zero dependents reflect a monorepo artifact, not quality — but they also mean no support surface, no standalone docs, and no community patterns.
• Look elsewhere when multichannel requirements diverge significantly from Sylius's channel abstraction and would require custom domain modeling beyond platform capabilities.
• Look elsewhere when the actual need is interoperability with a running Sylius instance — that belongs at the API/message boundary, not at the Composer level, and runtime co-hosting of Sylius inside Laravel is economically indefensible.

How to Pitch It (Stakeholders)

Executive summary. This is not a standalone product and not a Laravel package; it is a small, read-only component inside Sylius's multichannel commerce platform. Its strategic value depends entirely on one upstream decision: whether we adopt Sylius as our commerce platform. The MIT license is favorable, but with 3 stars, zero dependents, and no standalone issue tracker or documentation, we should not treat it as a separately maintained dependency. If multichannel commerce is a priority, the right investment is a focused Sylius platform evaluation that uses this bundle as a requirements blueprint — not adoption of the bundle in isolation.

Engineering summary. Treat sylius/channel-bundle as an internal Sylius component for channel integration and never add it as a direct dependency in non-Sylius applications. In a Sylius deployment it is a zero-cost, version-locked part of the platform; in a Laravel application it installs a Symfony/Doctrine dependency tree the framework will never boot. If we stay Laravel-based, use it as a reference implementation of channel semantics — channel entity with code, hostname, default locale and currency, tax-zone pointer, channel↔product and channel↔pricing joins, a ChannelContext resolved in middleware, and scoping enforced at the query-builder layer so catalog and pricing cannot leak across channels. Validate that with a roughly one-sprint spike against real catalog and pricing data before committing to broader tax and fulfillment work. The principal risks are commercial rather than technical and are silent when they fail: cross-channel price leakage, wrong currency or locale from misconfigured hostnames, orders attached to the wrong channel, and catalog visibility bleed. Every additional channel multiplies price rows, content, and tax/shipping configuration, so channel count should be treated as a product decision with a real operating cost. If we pursue Sylius, plan to contribute upstream to the main monorepo; if we remain Laravel-based, exclude this package from build-vs-buy options and budget one named owner to carry the channel domain internally.