refactor(openapi): cleaner approach to prepareOas helper#1312
refactor(openapi): cleaner approach to prepareOas helper#1312kanadgupta merged 3 commits intonextfrom
prepareOas helper#1312Conversation
| } = {}, | ||
| ) { | ||
| let specPath = path; | ||
| export default async function prepareOas(this: OpenAPICommands) { |
There was a problem hiding this comment.
args are no longer required since we can grab all of it from the this context ✨
| let specPath = path; | ||
| export default async function prepareOas(this: OpenAPICommands) { | ||
| let specPath = this.args.spec; | ||
| const command = this.id satisfies `openapi ${OpenAPIAction}`; |
There was a problem hiding this comment.
this allows us to assert that the command id property matches predefined the openapi {action} structure... common TS + oclif w
|
|
||
| static flags = { | ||
| out: Flags.string({ description: 'Output file path to write resolved file to' }), | ||
| title: titleFlag, |
There was a problem hiding this comment.
What's the resolve command doing with this?
There was a problem hiding this comment.
just for consistency i've mostly had it where every command that ends up outputting a new OAS file (i.e., pretty much every command besides inspect and validate) could benefit from this flag since it allows people to set custom info.title fields on the output
|
🎉 This PR is included in version 10.5.0-next.2 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version 10.5.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
🧰 Changes
as part of the work in #1313, this PR refactors our
prepareOashelper (and by extension, the entireopenapifamily of commands) to be a little bit more conformant to the oclif command class pattern. this will clean up our debug logs a bit and should make it a bit easier to add newopenapicommands going forward.🧬 QA & Testing
no end user changes — if tests continue to pass we should be in good shape!