Larecipe Swagger Laravel Package

Product Decisions This Supports

• Developer-experience roadmap bets: whether interactive, self-hosted API docs ("try it out" from inside the docs) are worth investing in as a lever for activation, time-to-first-successful-API-call, partner-integration cycle time, and support-ticket deflection. This package is a cheap way to prototype that hypothesis before committing roadmap capacity.
• Build vs. buy vs. borrow: it represents the "borrow" option — MIT-licensed, drop-in Swagger UI inside LaRecipe's Markdown docs, versus buying a hosted docs platform (ReadMe, Stoplight, SwaggerHub) or building an internal docs console. Useful as a price/effort anchor in that comparison, not as a long-term line item.
• Docs stack standardization: whether to go OpenAPI-spec-first (spec as the source of truth, renderer is swappable) or framework-coupled docs (LaRecipe pages + embedded UI). This package nudges toward the former; the decision itself is the deliverable.
• Internal vs. external documentation scope: suitable input to a decision on standing up an internal API reference for platform/QA/onboarding, where "good enough and free" beats "polished and procured."
• Sunset/consolidation calls: with an archived repo, zero dependents, and a 2019 last release, this is also evidence for the decision not to fragment the docs toolchain across one-off LaRecipe addons.
• Pre-sales / demo enablement: a fast way to show a live API console in a Laravel-hosted doc site during partner or prospect evaluations without a separate environment.

When to Consider This Package

Consider it when all of the following hold:

• You already run LaRecipe on a legacy Laravel app (roughly Laravel 5.5–6.x / PHP 7.x era) and are pinned to the LaRecipe major version this addon targets.
• The docs are internal or low-stakes — onboarding, QA, platform reference — not a contractual, customer-facing surface.
• You need "Try it out" against a live/sandbox API inside the docs, and a 1–2 day spike is cheaper than evaluating a hosted vendor.
• You are treating it as a reference implementation or fork candidate, with someone owning the fork (MIT permits this), rather than adding an unmaintained dependency you expect upstream to fix.
• Your security/compliance review tolerates an archived dependency confined to the documentation layer, with no production runtime or customer-data path.

Look elsewhere when any of these apply:

• New projects. Laravel 9/10/11 and PHP 8.2+ are almost certainly out of scope for a 2019 release; assume incompatibility until proven otherwise.
• Customer- or partner-facing documentation that needs OAuth2/API-key flows, versioned specs, changelogs, or an uptime commitment.
• OpenAPI 3.1 or modern spec tooling is required.
• You need collaboration, mock servers, contract testing, or CI spec linting — that's a docs platform decision, not an addon decision.
• Maintenance risk is unacceptable: archived means no CVE response, no framework upgrade path, no support. With zero dependents, you are the only user — you inherit 100% of the maintenance.
• Low opportunity signal: the surrounding opportunity score suggests limited market pull and a thin community, so expect no ecosystem help and no hiring pool familiar with it.

Practical alternatives in the same "self-hosted interactive docs" slot: render the OpenAPI spec with a maintained renderer (Swagger UI, Redoc, Scalar, Stoplight Elements) directly in a Blade view or static docs build — you keep the "try it out" experience and drop the abandoned glue layer.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, free, MIT-licensed addon that puts a live "try it out" API console inside Laravel-hosted documentation. It's not a strategic purchase decision — it's a low-cost probe of a real developer-experience lever: interactive docs tend to shorten partner integration time and reduce "how do I call this endpoint" support load. The catch is that it was last released in 2019 and the repository is archived, so we should not build a customer-facing commitment on it. Recommendation: fund a short spike to measure the developer-experience upside, but standardize the eventual solution on an OpenAPI-spec-first renderer that is actively maintained. Treat this package as a prototype and a price anchor, not a dependency.

To engineering: The value is the integration pattern, not the code. It demonstrates embedding Swagger UI into LaRecipe's Markdown-driven docs so engineers can execute requests against a sandbox from the same page they read. Expect to fork: no releases since mid-2019, no dependents, and the LaRecipe internals it hooks into have moved on. Keep it in the docs layer only, behind no production data path, and budget a day to verify compatibility with our Laravel/PHP versions before promising anything. If the spike succeeds, the durable version is a thin in-house Blade/route that serves a maintained OpenAPI renderer against our spec — same user outcome, no abandoned coupling, and it survives framework upgrades. If the spike fails, we've spent a day and we have a clear, evidence-backed reason to buy or build.

Decision requested: approve a timeboxed spike (1–2 days, docs layer only) with an explicit no-adoption default; the deliverable is a recommendation on OpenAPI-first docs tooling, not a merged dependency.