Closed davidebriani closed 4 weeks ago
YES 🙇
There is one major thing that I would like to see, but we will need to PR it to open_api_spex, which is a --check
option, which fails with a message if the open api spec that is generated does not match the existing one. This allows people to put this mix task in their CI pipeline to ensure that the files don't get out of sync.
Actually, perhaps we should make our own wrapper tasks that support the --check
option. This also gives us a chance to enrich those tasks further in the future if needed? i.e mix ash_json_api.spec.json
and mix ash_json_api.spec.yaml
?
For now, we can merge this as-is though, and consider that option as a follow up. Great work! 🥳
One other thing I'd like to follow up with is to support actually using the generated file, instead of regenerating it each time. This will make the schema faster to load as well.
The PR adds support for generating OpenAPI spec files with Mix tasks, instead of just in response to HTTP requests to the OpenAPI route.
Some new options are introduced that helps customizing the resulting spec:
:open_api_title
opt.:open_api_version
opt.conn
. Since we want to support spec generation from the CLI and without access to an active connection, a new option:phoenix_endpoint
is supported to statically provide a reference to the endpoint. Another option:open_api_servers
is added if the user instead wants to specify a custom list of URLs.The OpenAPI spec can be written to file using the Mix tasks provided by OpenApiSpex.
A new section is added to the documentation to describe how to use the new options and how to generate the spec file via CLI.
Fixes #129
Contributor checklist