Bridge Laravel Package

Product Decisions This Supports

• Almost none directly — and that itself is the decision. swp/bridge is a read-only subtree split of an internal component of Superdesk Web Publisher (SWP), a Symfony-based editorial publishing platform. It is not a general-purpose library that solves a recurring product problem; it is glue code that lets SWP's content repository (articles, tenants, revisions) feed its rendering layer (templates, controllers, routing). A PM should treat it as evidence about SWP's architecture, not as a candidate dependency.
• CMS/editorial platform evaluation (the one real use case). If your roadmap includes a headless or hybrid publishing stack — multi-tenant sites, editorial workflows, article rendering pipelines — reading this component tells you how tightly SWP couples content modeling to its Symfony rendering layer. That informs a build vs. buy call: buy a maintained CMS (Contentful, Strapi, Payload, or even a supported SWP host) versus composing one from SWP's parts, most of which are not independently releasable.
• Architecture-risk input, not a feature input. It helps answer "can we extend a Superdesk-based platform in-house?" — the answer being yes only with deep Symfony and SWP-internal knowledge, since this package is a distributed artifact of a monorepo, not a stable contract with external consumers.
• Roadmap signal on vendor health. Last release June 2018, one GitHub star, zero dependents. Any roadmap item that assumes this component will receive fixes, PHP 8.x compatibility, or security patches is unowned risk. Do not let a "use the Superdesk components" plan absorb this without an explicit maintenance owner.

When to Consider This Package

Adopt only when all of the following hold:

1. You are already committed to Superdesk Web Publisher at the platform level (not evaluating it), and you need the specific content-to-template bridge behavior it provides.
2. You are pinning the matching SWP monorepo version — because this split is generated from that tree, mixing this tag with a different SWP version is unsupported and untested.
3. Your legal team has cleared AGPL-3.0 for your deployment model. This is the single biggest gate: AGPL's network-copyleft obligation is usually disqualifying for a proprietary SaaS product unless you are prepared to publish the corresponding source of the modified work.
4. You have a named owner who will vendor-fork it and carry PHP-version and security maintenance, since upstream activity is effectively nil.

Look elsewhere — aggressively — if any of these are true: you want a standalone rendering or templating library (use Twig/Symfony directly); you need an actively maintained dependency with a semantic versioning contract (zero dependents and a 2018 last release mean no ecosystem pressure to keep it correct); you are assessing a commercial or closed-source product (AGPL exposure); you were hoping to "just install one Superdesk piece" — the components are not designed to be consumed individually, and this subtree split exists for distribution mechanics, not for external reuse.

How to Pitch It (Stakeholders)

To executives: This is not a component we should adopt. It is an internal part of an open-source publishing platform, published as a read-only artifact, last updated in 2018, with no downstream users. Two facts drive the recommendation: the AGPL-3.0 license, which can obligate us to release source for a network-served product, and the absence of maintenance, which means we would own all future bug and security fixes ourselves. Recommendation: do not add it to the stack; if the business wants a publishing platform, evaluate SWP (or a hosted Superdesk offering) as a whole, or a maintained commercial CMS — and price in the licensing review either way.

To engineering: Treat swp/bridge as a read-only view into SWP's monorepo, not a consumable library. It carries no versioned contract for outside users, its release cadence stopped in 2018, and it presumes the surrounding SWP bundles. If we pursue SWP, vendor the monorepo at a pinned commit rather than assembling from these splits, budget for PHP runtime upgrades and security patching ourselves, and get legal sign-off on AGPL before the first line of integration code. If the goal was simply "render content with templates," we can meet it directly with Symfony and Twig at a fraction of the coupling and legal overhead.