Radish Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for vendor integration. The only defensible reason to adopt jadu/radish-bundle is that you are already a Radish/Jadu customer and need a PHP-side adapter instead of writing your own client. The decision it informs is narrow: "do we take a dependency on the vendor's own glue code, or do we write a 200-line HTTP client against the same API?"
• Content sourcing and syndication roadmap. If your roadmap includes pulling structured/published content from an external publishing platform into a product surface (public site, portal, service directory, intranet), this package is a candidate connector — not a platform choice.
• Migration and exit planning. Useful as a reference implementation when scoping a migration off a legacy CMS: it tells you what the vendor considers the supported integration surface, which is itself roadmap input.
• Feature scoping for "integrate with X" requests. Lets you price an integration as days (wrap an existing bundle) rather than weeks (build a connector), provided the bundle's coverage matches the fields and operations you actually need.
• Explicitly not supported: market validation. 0 stars, 0 dependents, 0 score, and a low opportunity score mean this package provides no evidence of ecosystem demand or third-party production use. Do not cite it in a build/buy memo as proof that "the community is standardising on this approach."

Caveat to carry into any decision: metadata here is sparse and the artifact is named *-Bundle, which is Symfony bundle convention, not Laravel package convention. Treat it as a vendor adapter to be evaluated against its source, not as a Laravel-native library.

When to Consider This Package

Consider it when all of these hold:

• You have an existing Radish/Jadu relationship — contract, pilot, or an active procurement — so the vendor dependency already exists and this package adds no new lock-in.
• You need server-side PHP access to Radish content and the bundle's exposed operations cover your required read/write surface (verify against source, not README).
• You are willing to wrap it behind your own interface and pin an exact version/commit, so an abandonment doesn't become an incident.
• Your stack can absorb Symfony-style bundle wiring into Laravel's container — or you're on Symfony already, in which case the integration tax disappears.
• MIT licensing and vendor-only maintenance are acceptable to your legal/security review.

Look elsewhere when any of these hold:

• You are Laravel-first and want idiomatic Laravel. Bundle conventions (DI extension, config tree, kernel wiring) do not map cleanly onto Laravel service providers. Budget real integration work; do not assume composer require is the whole story.
• You need support guarantees. Zero stars, zero dependents, zero community answers means your only escalation path is the vendor's commercial relationship. No SLA, no Stack Overflow corpus, no third-party blog posts.
• You are choosing a content platform, not integrating one. This is not a CMS. Choose the platform on product grounds first; the connector is a downstream detail.
• Your decision criteria include adoption signals. A package with no dependents is a single-maintainer risk by definition; if your architecture review gates on ecosystem health, this fails the gate.
• A generic HTTP client would do. If you need three endpoints, Illuminate\Http\Client plus a thin repository class is cheaper to own than a dependency you must track.

How to Pitch It (Stakeholders)

To executives — one paragraph:

This is a free (MIT), vendor-maintained connector that lets our PHP application read from the Radish publishing platform. It is worth adopting only if we are already paying for Radish — in that case it compresses an integration from weeks to days and carries no licence cost. It is not a strategic bet and not a platform decision: the package has no independent user base, so we should treat it as vendor glue, contain it behind our own interface, and retain the ability to replace it with a small in-house client. Recommended position: adopt conditionally, contained.

To engineering — the ask:

• Timebox a spike: read the source, confirm the operations and data shapes we need, and confirm it installs without fighting Laravel's container.
• If it passes: vendor it behind our own repository/interface, pin the exact version, and add a contract test so a swap to a hand-rolled HTTP client is a contained change.
• If it fails: fall back to a thin HTTP client against the same API. Estimated cost is small and the exit risk drops to zero.
• Do not let it leak into domain code. No bundle/Symfony types in our application layer.

Bottom line for the decision log: low-cost, low-signal, single-vendor dependency. Adopt only as a consequence of an existing Radish commitment; never as a reason to make one.