Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Swagger Generator

Swagger Generator Laravel Package

infyomlabs/swagger-generator

Generate Swagger/OpenAPI documentation for Laravel APIs directly from your routes and controllers. InfyomLabs Swagger Generator automates spec creation, reduces manual annotation work, and helps keep interactive API docs in sync with your codebase.

View on GitHub
Deep Wiki
Context7

Swagger Generator for InfyOm Laravel Generator

Frequently asked questions about Swagger Generator
Does infyomlabs/swagger-generator support Laravel 11 and Laravel 12?
The latest tagged release, v3.2.0 from April 2023, targets Laravel 10, and there is no published claim of Laravel 11 or 12 support. Absence of a claim is not proof of breakage, but treat it as unverified until a smoke test proves otherwise for your exact Laravel and PHP versions. A branch install plus one artisan run against a real controller group answers it faster than reading source.
How do I install and configure infyomlabs/swagger-generator in a Laravel app?
Install it as a dev dependency with composer require --dev infyomlabs/swagger-generator, publish the package configuration, and run the generator artisan command to emit a swagger.json. Then open the route the package exposes to view Swagger UI against your API. The mechanics are deliberately light and do not add anything to the production request path.
Do I need InfyOm Laravel Generator to use this Swagger generator package?
No, it runs standalone, but its headline value is tied to the InfyOm scaffolding workflow it was built alongside. If your codebase is not InfyOm-generated, the offer narrows to run a command and get a rough spec, which is a crowded field. Compare it against a maintained auto-generator before adopting it for a non-InfyOm service.
Does the generated spec capture form request validation rules and error responses?
Auto-inference from routes, controller method signatures, and model schema typically captures the path, HTTP verb, and a rough schema. It generally does not capture form request validation rules, authorization scopes, error response shapes, pagination envelopes, or content negotiation. Those gaps surface when a consumer integrates against docs that never matched the controllers, so plan to annotate or hand-edit the missing parts.
Should swagger-generator be a dev dependency or a production requirement?
Install it as a --dev dependency. It is a development-time documentation artifact that reads your route table and controller signatures, not a runtime library, and it should not appear in the production request path. Running the generator as a deploy build step is fine; loading it in production buys you nothing.
How does infyomlabs/swagger-generator compare to Scramble and Scribe?
dedoc/scramble and knuckleswtf/scribe both auto-generate API documentation with active maintenance and larger communities. This package's real differentiator is its fit with the InfyOm scaffolding toolset, not raw generation capability. If you are not on InfyOm, a maintained alternative is usually the better default for the same effort.
Is infyomlabs/swagger-generator still maintained?
It has a single release, v3.2.0, dated April 2023, around 114 GitHub stars, a community-only issue tracker, and no visible LTS, deprecation, or CVE response policy. The MIT license lets you fork it, but the trajectory is atrophying while Laravel majors keep moving. Budget for owning a fork if the package becomes load-bearing.
Can I customize the generated swagger.json or its templates?
The package ships a generator plus templates, so you can publish and edit the templates instead of hand-patching the output each time. That is the right lever for house conventions the parser does not infer, such as custom response envelopes or auth headers. Keep template edits in version control so the drift between code and spec stays reviewable.
Should I commit the generated swagger.json to version control?
Either approach works, but decide deliberately rather than by accident. Regenerating the spec as a build artifact keeps it honest to the code, whereas a checked-in swagger.json is a file you own and must maintain by hand if the package stalls. Name an owner for that file before adoption so the question does not get answered by default.
How do I view the generated docs, and can I validate the spec in CI?
The package emits a swagger.json and serves a Swagger UI view you can open in the browser during development. Treat that UI as an internal tool unless you deliberately scope it as a public docs product. In CI, validate the emitted file against the OpenAPI schema so silent drift fails a build instead of reaching an integrator.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
cgv/localized-resource
noith/settings
kda/laravel-package
kda/filament-dynamic-navigation
bypersoft/signbox
pairus/product-data
fayne/laravel-filament-cms-core
nodisrupt/laravel-agent
sierratecnologia/media-manager