feat: adding support to oas-to-snippet for alternative language targets #1261
Conversation
erunion
added
the
type:enhancement
| const harOverride = { | ||
| log: { | ||
| entries: [ | ||
| { | ||
| request: { | ||
| method: 'GET', | ||
| url: 'https://dash.readme.io/api/v1/categories/', | ||
| httpVersion: 'HTTPS/1.1', | ||
| headers: [ | ||
| { | ||
| name: 'authorization', | ||
| value: 'Basic xxx', | ||
| }, | ||
| ], | ||
| queryString: [], | ||
| }, | ||
| }, | ||
| ], | ||
| }, | ||
| }; |
There was a problem hiding this comment.
Removed this hardcoded HAR in favor of using one that I copied from HTTPSnippet into https://github.com/readmeio/har-examples (we use this repo for testing api snippets).
| }; | ||
|
|
||
| const codeSnippet = generateCodeSnippet(oas, operation, {}, {}, 'node', oasUrl, harOverride); | ||
| const codeSnippet = generateCodeSnippet(null, null, null, null, 'node', null, harExamples.full); |
There was a problem hiding this comment.
Made all of these arguments null because the only ones that should be getting picked up are the language and override.
| if ('opts' in supportedLanguages[lang].httpsnippet.targets[target]) { | ||
| // eslint-disable-next-line jest/no-conditional-expect | ||
| expect(supportedLanguages[lang].httpsnippet.targets[target].opts).toStrictEqual(expect.any(Object)); | ||
| } | ||
|
|
||
| if ('install' in supportedLanguages[lang].httpsnippet.targets[target]) { | ||
| // eslint-disable-next-line jest/no-conditional-expect | ||
| expect(supportedLanguages[lang].httpsnippet.targets[target].install).toStrictEqual(expect.any(String)); | ||
| } |
There was a problem hiding this comment.
I don't really like this conditional testing, but Jest doesn't offer any "assert this value as something if it exists, if it doesn't its ok". I could do an assertion on this with JSON Schema but that'd require loading in ajv or some other validator. No thanks!
| @@ -1,80 +1,212 @@ | |||
| const supportedLanguages = { | |||
| module.exports = { | |||
There was a problem hiding this comment.
I should note that by putting all these alternative targets into these configs that we're going to be exposing them in the APIRequest module with some work I'm doing to support custom code samples for manual APIs. Shouldn't be a problem, but FYI regardless.
🧰 What's being changed?
This updates
@readme/oas-to-snippetto add support alternative language targets!Previously if you wanted to generate a Node snippet, you'd do:
This would generate you a
node-fetchsnippet and that's great but HTTPSnippet offers all sorts of other Node targets likeaxiosorrequestthat you couldn't use — with this change you can now do the following:With the
languageargument as an array we'll now do a lookup in our supported targets fornodeand ifaxiosis there we'll generate an Axios snippet!🧬 Testing
I've mostly rewritten
supportedLanguagesand the core language determination in this library along with a ton of new tests for this and all of the new targets we're now exposing, but with that there's a few points:nodewill continue to map tonode-fetch.node-simplefrom the list ofsupportedLanguagesin favor of treating it as a proper alternative target fornode. To retain backwards compatibility with the rest of these changes, supplyingnode-simpleas the language arg (and having it within your OAS inx-samples-languages) will continue to work.supportedLanguageswithin ReadMe and thankfully the overhauls to the structure of this object won't affect anything there.