Weave Code
Bridge Bundle Laravel Package
swp/bridge-bundle
A Symfony bundle that bridges SWP components into your application, handling service wiring and configuration so integration stays simple. Lightweight glue for registering services, exposing bundle settings, and keeping framework setup minimal.
[READ-ONLY] Subtree split of the Superdesk Web Publisher Bridge Bundle
Frequently asked questions about Bridge Bundle
- Does swp/bridge-bundle work with Laravel?
- Not as a native package. It is a Symfony bundle that relies on Symfony's Bundle registration, kernel bootstrapping, and compiler-pass model, none of which Laravel implements. You would have to port its service wiring into a Laravel service provider, which defeats the purpose of the package. For a Laravel app, consume Superdesk Web Publisher over its HTTP API instead.
- What is swp/bridge-bundle actually for?
- It is lightweight glue from the Superdesk Web Publisher ecosystem that registers SWP services and configuration inside a Symfony application. The 'bridge' refers to bridging SWP content components into a Symfony host, not to Laravel. It exposes bundle configuration and relies on Symfony's dependency injection container and autowiring to wire services.
- Can I install swp/bridge-bundle in a Laravel 10 or 11 project with Composer?
- An install will almost certainly fail or create conflicts. The last release was in June 2018 and targets PHP 7-era platforms with Symfony 3.x or 4.x component constraints, so Composer will clash with Laravel 10/11's PHP 8.2+ and modern Symfony component requirements. Read the composer.json in the split repository before attempting any spike. Do not add it to a production Laravel composer.json.
- Is swp/bridge-bundle still maintained?
- The split repository shows a last release on 2018-06-08 and is a read-only subtree split with zero stars and zero dependents. Issues and pull requests live in the upstream SuperdeskWebPublisher monorepo, so you must verify activity there separately. Treat the package as abandoned until the upstream proves otherwise.
- What license does swp/bridge-bundle use?
- It is AGPL-3.0, which is a major adoption risk for proprietary or SaaS products. Section 13's network-use clause can trigger source-disclosure obligations when a modified or derived work is exposed over a network. This is a legal review item, not a technical footnote. For most commercial Laravel applications, the answer will be no.
- How should I integrate Superdesk Web Publisher with Laravel without this bundle?
- Use API-boundary integration. Call the SWP REST API with Laravel's HTTP client or a thin typed wrapper, map responses into your own DTOs, and keep an anti-corruption layer around the SWP contract. This avoids the Symfony framework mismatch, keeps your codebase clean of AGPL code, and isolates upstream changes. If you need the full SWP runtime, run it as a separate sidecar service and talk to it over HTTP or a queue.
- What PHP and Symfony versions does swp/bridge-bundle require?
- Expect Symfony 3.x or 4.x component constraints and PHP 7-era platform requirements based on the 2018 release date. Those pins will not resolve cleanly against PHP 8.2 or 8.3 and modern Symfony components. Always read the split repository's composer.json for the authoritative constraint set. If it requires symfony/symfony ^3.x, stop.
- What is the 'bridge' in swp/bridge-bundle bridging to?
- It bridges Superdesk Web Publisher components into a Symfony application by registering services and exposing bundle configuration, so you avoid manual bootstrapping in the kernel. It does not bridge to Laravel. The name is easy to misread in a Laravel package search, which is why it appears in the wrong context.
- Is swp/bridge-bundle safe for production use?
- No. It is unmaintained since 2018, has no community validation, no security review, and no issue triage at the split repository level. Abandoned dependencies are a silent-CVE risk because no patches will ever ship. Combined with AGPL-3.0 licensing, it is not a suitable production dependency for a Laravel application.
- How can I evaluate swp/bridge-bundle safely before deciding?
- Treat it as a specification artifact rather than a dependency. Read its service definitions and DTOs to derive the SWP API contract, then implement a Laravel-native adapter. If you must trial-install it, use a disposable Symfony sandbox container with PHP 7.x, never your Laravel application. Confirm the upstream monorepo's health and get a legal opinion on AGPL before any engineering investment.
Weaver
How can I help you explore Laravel packages today?