- What does riconijeboer/laravel-to-swagger actually do?
- It is a Laravel developer tooling package that aims to give you the easiest way to create a Swagger / OpenAPI 3 specification for your Laravel APIs. It turns your application's routes and controllers into browsable API documentation so the spec stays aligned with the code you ship. It is a generator, not an API gateway or a hosted documentation platform. Think of it as a build-time or dev-time helper that emits a spec artifact you can review and commit.
- Is laravel-to-swagger compatible with Laravel 10, Laravel 11 and modern PHP versions?
- That is unproven and should be treated as a gating risk. The package was last released on 2022-02-15 and the repository is archived, so compatibility with Laravel 10, Laravel 11 and current PHP versions has not been verified upstream. Run a time-boxed proof of concept on a representative API slice before you commit to anything. Treat any untested Laravel and PHP combination as unsupported.
- How do I install and trial laravel-to-swagger safely?
- Install it as a dev dependency in a non-production branch rather than in your production runtime stack. Generate the spec for a handful of representative endpoints, validate the output, and commit the resulting artifact. If the output is useful, either keep it as a one-off generator or fork it internally; if it is not, remove it. Do not make it a runtime production dependency.
- Does it generate a static JSON/YAML spec or does it serve a Swagger UI?
- The package is positioned as a generator of the Swagger / OpenAPI 3 configuration, so the safest pattern is artifact-first: emit the spec and commit it. Whether it also serves an interactive Swagger UI out of the box should be confirmed in your proof of concept, since the documentation is thin and the project is archived. Either way, treat the generated file as the deliverable rather than a live endpoint.
- Does laravel-to-swagger infer routes and controllers automatically, or do I need annotations?
- It fits best with conventional Laravel routing and controller structures, which is what the package was built around. The exact mechanics, whether it introspects routes, reads annotations or attributes, or relies on manual configuration, should be verified against your own route patterns during the proof of concept. Test it against real endpoints that use middleware, authentication, form requests and API resources before drawing conclusions. Anything outside that tested surface should be considered unsupported.
- Is riconijeboer/laravel-to-swagger still maintained?
- No. The repository is archived and the last release was on 2022-02-15, so there is no upstream maintenance path. Adoption is low at around 22 stars, which means community-only support and limited public troubleshooting. Any continued use implies internal ownership, dependency pinning and periodic compatibility testing on your side.
- Can I use laravel-to-swagger in production?
- Not as a runtime production dependency. The sensible use is as a build-time or developer-time generator that produces a spec artifact you validate and version alongside your code. Because the package is archived, production use effectively means you own it. If you need it long term, fork it under an internal namespace, pin dependencies and assign clear ownership.
- How do I keep the generated OpenAPI spec accurate and validated in CI?
- Run generation in CI on a non-production branch and validate the output with an OpenAPI linter or validator before anything is published. Compare the generated spec against the actual routes, authentication schemes, request and response schemas and error responses. Version the resulting spec artifact so drift is visible in diffs. Without validation you risk false confidence in documentation that does not match real API behaviour.
- Does it support OpenAPI 3.0 vs 3.1, authentication schemes, schemas, examples and error responses?
- The package targets OpenAPI 3 / Swagger definitions, but feature depth for 3.0 versus 3.1, security schemes, component schemas, examples and error responses is not guaranteed and must be checked. Test each feature you rely on against a representative endpoint slice and confirm the output passes an OpenAPI validator. Where coverage is missing, plan to patch your internal fork or supplement the spec manually. Do not assume the generated document is complete or spec-compliant.
- What alternatives should I evaluate instead of adopting this package?
- Evaluate maintained, actively released generators in parallel rather than assuming this package is the long-term answer. Look at annotation or attribute-driven generators, route-introspection tools, and design-first specification workflows, and score them on Laravel version support, OpenAPI 3.1 coverage and CI validation. Alternatively, use laravel-to-swagger once to bootstrap a spec, then move to a maintained tool. The MIT license does allow an internal fork, but that shifts all maintenance ownership to your team.