New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: Migrate the openapi-generator from oclif to yargs #1661
Conversation
# Conflicts: # yarn.lock
# Conflicts: # yarn.lock
# Conflicts: # yarn.lock
# Conflicts: # yarn.lock
.github/workflows/build.yml
Outdated
@@ -15,7 +15,7 @@ jobs: | |||
strategy: | |||
matrix: | |||
os: [ubuntu-latest] | |||
node-version: [12.x] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Node 12 is in maintenance mode until Apr2022. Therefore I assume we should be okay to test with node 14 instead. This change is required to use fs/promises which are used in the generate-readme.ts script below. If this is a problem, we could replace fs/promises with utils.promisify or fs-extra instead. Just let me know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that was planned anyways for 2.0, right? Please document this in the new changelog-v2.md
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyways, maybe next time this could be a separate PR (for easier reverting if something goes wrong).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We planned to migrate to ES19 as it is supported by node14 and above. Since the readme script is not customer facing, this still means that we are node12 compatible but are no longer testing it explicitly...
You got a point with this being a separate PR. Should I do this already? I don't expect too much effort for splitting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks very good!
.github/workflows/build.yml
Outdated
@@ -15,7 +15,7 @@ jobs: | |||
strategy: | |||
matrix: | |||
os: [ubuntu-latest] | |||
node-version: [12.x] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that was planned anyways for 2.0, right? Please document this in the new changelog-v2.md
.github/workflows/build.yml
Outdated
@@ -15,7 +15,7 @@ jobs: | |||
strategy: | |||
matrix: | |||
os: [ubuntu-latest] | |||
node-version: [12.x] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyways, maybe next time this could be a separate PR (for easier reverting if something goes wrong).
} | ||
} catch (err) { | ||
logger.error(err); | ||
yargs.exit(1, new Error()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No error message? Is this intended?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We log the error with the logger in line 30. yargs itself does not handle our "errorWithCause" as we intend.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, maybe just add a short comment. If we exit with 1 and log an error before, it seems unnecessary to pass an empty error there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree but this was the only way I found to make it work due to the typing of yargs.exit()
. I'm open to suggestions, but maybe we should just add it to the follow up ticket instead.
@@ -82,26 +82,26 @@ describe('generator', () => { | |||
mock.restore(); | |||
}); | |||
|
|||
it('should transpile the generated sources', async () => { | |||
const files = await promises.readdir(outputPath); | |||
// it('should transpile the generated sources', async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment it back in? ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoops 😄 good catch
coerce: (input?: string): string | undefined => { | ||
if (typeof input !== 'undefined') { | ||
const isFilePath = | ||
(existsSync(input) && lstatSync(input).isFile()) || !!extname(input); | ||
return isFilePath | ||
? resolve(input) | ||
: resolve(input, 'options-per-service.json'); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this also work with async functions? I know that it didn't work with oclif, that is why it is implemented with sync functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To my understanding it does, but it causes the parsed type to be a promise i think... I would rather keep this change out of this initial ticket.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense
config?: string; | ||
} | ||
|
||
/** | ||
* Parsed options with default values. | ||
*/ | ||
export type ParsedGeneratorOptions = | ||
typeof OpenApiGenerator extends Parser.Input<infer F> ? F : never; | ||
export interface ParsedGeneratorOptions { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume with yargs there is no type that we can derive?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed, can be part of a follow up, but this is low prio
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Follow up ticket: https://github.com/SAP/cloud-sdk-backlog/issues/402 |
* Add yargs options * Fix types * Fix typo bug in parseGeneratorOptions * Fix config handling * Remove oclif and cli-ux * Improve types * Replace parsedGeneratorOptions * Fix tests * Fix tests * Revert change to cli option 'include' * Apply coerce if not using argv * Differentiate between GeneratorOpts and ParsedOpts * Fix tests (hopefully) * Revert change to options in generate-test-services * Debug integration tests * Add shebang * Fix tests * Fix typos * Fix integration tests * Fix tests * Use stricter version for @SAP packages * Generate readme * Add note to changelog * Use node 14 instead of 12 in GHActions * Revert node14 to node12 * Move index.ts to cli.ts * Rename flags.ts to options.ts # Conflicts: # yarn.lock
This refactoring removes
oclif
andcli-ux
in favor ofyargs
. There should be no changes in functionality or usage. There are some minor changes in behavior during edge cases and tiny changes in the generated help description.I also changed the github actions to run with node14 (current LTS) rather than node12. To make it possible to merge this PR, I removed the requirement for the node12 tests to pass. After this is merged (or if you disagree with this change), the requirement should be added again (with the matching node version).
TODO:
Closes SAP/cloud-sdk-backlog#280