Skip to content
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

Merged
merged 35 commits into from Oct 15, 2021

Conversation

florian-richter
Copy link
Contributor

@florian-richter florian-richter commented Oct 8, 2021

This refactoring removes oclif and cli-ux in favor of yargs. 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:

  • Fix tests
  • Generate README
  • Test end to end

Closes SAP/cloud-sdk-backlog#280

@florian-richter florian-richter marked this pull request as ready for review October 13, 2021 11:51
@@ -15,7 +15,7 @@ jobs:
strategy:
matrix:
os: [ubuntu-latest]
node-version: [12.x]
Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor

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).

Copy link
Contributor Author

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.

Copy link
Contributor

@marikaner marikaner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks very good!

@@ -15,7 +15,7 @@ jobs:
strategy:
matrix:
os: [ubuntu-latest]
node-version: [12.x]
Copy link
Contributor

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

@@ -15,7 +15,7 @@ jobs:
strategy:
matrix:
os: [ubuntu-latest]
node-version: [12.x]
Copy link
Contributor

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());
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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 () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment it back in? ;)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops 😄 good catch

packages/openapi-generator/src/options/flags.ts Outdated Show resolved Hide resolved
CHANGELOG.md Show resolved Hide resolved
Comment on lines 95 to 102
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');
}
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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 {
Copy link
Contributor

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?

Copy link
Contributor

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

Copy link
Contributor

@marikaner marikaner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@florian-richter
Copy link
Contributor Author

Follow up ticket: https://github.com/SAP/cloud-sdk-backlog/issues/402

@florian-richter florian-richter merged commit ccbca93 into main Oct 15, 2021
@florian-richter florian-richter deleted the yargs-openapi-generator branch October 15, 2021 14:36
florian-richter pushed a commit that referenced this pull request Oct 18, 2021
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants