refactor: Migrate the openapi-generator from oclif to yargs

.github/actions/get-changelog/action.yml

@@ -4,5 +4,5 @@ outputs:
   changelog:
     description: 'The current changelog'
 runs:
-  using: 'node12'
+  using: 'node14'
   main: 'dist/.github/actions/get-changelog/index.js'

.github/workflows/build.yml

@@ -15,7 +15,7 @@ jobs:
     strategy:
       matrix:
         os: [ubuntu-latest]
-        node-version: [12.x]
+        node-version: [14.x]
     steps:
       - uses: actions/checkout@v2
       - run: git fetch --depth=1
@@ -42,7 +42,7 @@ jobs:
       - run: git fetch --depth=1
       - uses: actions/setup-node@v2
         with:
-          node-version: '12.x'
+          node-version: '14.x'
       - uses: actions/cache@v2
         id: cache
         with:
@@ -72,7 +72,7 @@ jobs:
       - run: git fetch --depth=1
       - uses: actions/setup-node@v2
         with:
-          node-version: '12.x'
+          node-version: '14.x'
       - uses: actions/cache@v2
         id: cache
         with:
@@ -91,7 +91,7 @@ jobs:
       - run: git fetch --depth=1
       - uses: actions/setup-node@v2
         with:
-          node-version: '12.x'
+          node-version: '14.x'
       - uses: actions/cache@v2
         id: cache
         with:
@@ -116,7 +116,7 @@ jobs:
       - run: git fetch --depth=1
       - uses: actions/setup-node@v2
         with:
-          node-version: '12.x'
+          node-version: '14.x'
       - uses: actions/cache@v2
         id: cache
         with:

.github/workflows/bump.yml

@@ -17,7 +17,7 @@ jobs:
           token: ${{ secrets.GH_CLOUD_SDK_JS_ADMIN_WRITE_TOKEN }}
       - uses: actions/setup-node@v2
         with:
-          node-version: '12.x'
+          node-version: '14.x'
       - run: yarn install --frozen-lockfile
       - name: Setup git
         run: |

.github/workflows/release.yml

@@ -11,7 +11,7 @@ jobs:
       - uses: actions/checkout@v2
       - uses: actions/setup-node@v2
         with:
-          node-version: '12.x'
+          node-version: '14.x'
       - run: yarn install --frozen-lockfile
       - name: Stable Release
         run: |

.github/workflows/tests-windows.yml

@@ -13,7 +13,7 @@ jobs:
     strategy:
       matrix:
         os: [windows-latest]
-        node-version: [12.x]
+        node-version: [14.x]
     steps:
       - uses: actions/checkout@v2
       - run: git fetch --depth=1

CHANGELOG.md

@@ -42,6 +42,7 @@ Blog: TBD<br>
 ## Improvements
 
 - [generator] Include and exclude options added to the `transpileDirectory()` method
+- [openapi-generator] Replace `oclif` library with `yargs`. This is a refactoring without functional changes.
 
 ## Fixed Issues
 

STYLEGUIDE.md

@@ -7,7 +7,7 @@ Those that are checked by lint are marked by the following symbol: ✓.
 #### Table of Contents
 
 - [Naming](#naming)
-  - [Use kebap case for file names](#use-kebap-case-for-file-names)
+  - [Use kebab case for file names](#use-kebab-case-for-file-names)
   - [Use camel case for variable names ✓](#use-camel-case-for-variable-names-)
   - [Use pascal case for classes ✓](#use-pascal-case-for-classes-)
   - [Use pascal case for interface names and don't prefix them](#use-pascal-case-for-interface-names-and-dont-prefix-them)
@@ -45,9 +45,9 @@ Those that are checked by lint are marked by the following symbol: ✓.
 
 ## Naming
 
-### Use kebap case for file names
+### Use kebab case for file names
 
-Use kebap case for all file names and directories, except for generated files and markdown files, that are not in the knowledge base.
+Use kebab case for all file names and directories, except for generated files and markdown files, that are not in the knowledge base.
 
 ❌ Examples of **incorrect** code:
 
@@ -65,7 +65,7 @@ some_dir / some_class.ts;
 ✅ Examples of **correct** code:
 
 ```ts
-/* Use kebap case */
+/* Use kebab case */
 some-dir/some-class.ts
 
 /* Exceptions apply for generated files and some markdown files */
@@ -122,7 +122,7 @@ class FooBar {
 ### Use pascal case for interface names and don't prefix them
 
 Pascal case is common in most JavaScript/TypeScript projects for interfaces.
-Don't prefix interfaces with the hungarian notation 'I' (or other prefixes).
+Don't prefix interfaces with the Hungarian notation 'I' (or other prefixes).
 If you have a class with the same name as an interface, consider a more general name for the interface or a more specific name for the class - if they are different things it should be possible to name them differently.
 
 ❌ Examples of **incorrect** code:
@@ -200,7 +200,7 @@ function parseJson() { ... }
 
 Every function should do something and that action should be described with a verb.
 The verb should fit the return type and value.
-An exception to this can be methods, that operate on an instance directly, e. g. `instance.toString()`, `instance.asObject()`.
+An exception to this can be methods, that operate on an instance directly, e.g. `instance.toString()`, `instance.asObject()`.
 
 ❌ Examples of **incorrect** code:
 
@@ -253,7 +253,7 @@ class FooBar {
 
 ### Use single quotes ✓
 
-Use single quotes, unless not possible otherwise, e. g. when your string contains single quotes.
+Use single quotes, unless not possible otherwise, e.g. when your string contains single quotes.
 
 ❌ Examples of **incorrect** code:
 
@@ -301,7 +301,7 @@ const foo = `foo ${fn(bar + 'bar')}`;
 ### Use `.forEach` and other array functions rather than `for`
 
 Use the functional language concepts of JavaScript in favor of the imperative ones, when possible.
-Use the correct function for your use case (e. g. `.map`, `.reduce`, `.filter`, `.find`, `.some`, `.every`).
+Use the correct function for your use case (e.g. `.map`, `.reduce`, `.filter`, `.find`, `.some`, `.every`).
 In some cases it makes sense to resort to the imperative `for`, for example, when performance is of the essence, if you have to iterate over every n-th element or if you want to execute asynchronous actions sequentially.
 Be aware of the effects of asynchronicity.
 The callback passed to `.forEach` is invoked for every item of a list sequentially.
@@ -395,7 +395,7 @@ function foo(obj: SomeType | undefined) {
 ### Use `null` for intentional explicit absence of values or if it is part of an external API
 
 If a value can both be non-existent and intentionally absent and those states are semantically different it may make sense to allow the usage of `null`.
-Those cases should however be rather rare and are more common when calling external APIs, e. g. through HTTP requests.
+Those cases should however be rather rare and are more common when calling external APIs, e.g. through HTTP requests.
 Consider whether there is a better API design that might avoid this.
 
 ❌ Examples of **incorrect** code:
@@ -425,45 +425,45 @@ function foo(obj: SomeType | null | undefined) {
 ### Use truthy/falsy checks where possible
 
 In most cases it is possible to check for truthiness/falsiness instead of explicitly comparing values.
-This should be used when possible, but carefully considered in cases where falsy values are valid and therefore semantically truthy values, e. g. 0, ''.
+This should be used when possible, but carefully considered in cases where falsy values are valid and therefore semantically truthy values, e.g. 0, ''.
 Therefore, when checking for existence of primitives, don't use truthy/falsy checks.
 Of course, more fine granular checks should be applied if semantically needed.
 
 ❌ Examples of **incorrect** code:
 
 ```ts
 /* Don't use explicit comparison with `undefined` for objects */
-if(obj !== undefined) { ... }
+if (obj !== undefined) { ... }
 
 /* Don't use truthy/falsy checks for existence of primitives */
 function checkIfExist(obj: string | number) {
-  if(obj) { ... }
+  if (obj) { ... }
 }
 
 /* Don't use explicit comparison for array length (or other numbers)*/
-if(arr.length !== 0) { ... }
+if (arr.length !== 0) { ... }
 
 /* Don't use explicit comparison for booleans */
-if(isFoo !== false) { ... }
+if (isFoo !== false) { ... }
 
 /* Don't use explicit comparison when checking for empty string */
-if(someString !== '') { ... }
+if (someString !== '') { ... }
 ```
 
 ✅ Examples of **correct** code:
 
 ```ts
 /* Use truthy/falsy check for objects */
-if(obj) { ... }
+if (obj) { ... }
 
 /* Use truthy/falsy check for array length (or other numbers)*/
-if(arr.length) { ... }
+if (arr.length) { ... }
 
 /* Use truthy/falsy for booleans */
-if(!isFoo) { ... }
+if (!isFoo) { ... }
 
 /* Use truthy/falsy check when checking for empty string */
-if(someString) { ... }
+if (someString) { ... }
 ```
 
 ## White space
@@ -483,7 +483,7 @@ arr.forEach(item => {
 
 /* Don't use tabs */
 arr.forEach(item => {
-⇥const property = item.property;
+  const property = item.property;
 });
 ```
 
@@ -556,7 +556,7 @@ There should be no empty lines in between, except if it is part of the descripti
 ### Use `@deprecated` tag for deprecation
 
 When deprecating public API, this is done through the TypeDoc comments.
-The first line of the comment should start with `@deprecated` followed by a note mentioning since which version this is deprecated (e. g. `Since v1.0.0.`) and a note of what to use instead (or alternatively that it won't be replaced).
+The first line of the comment should start with `@deprecated` followed by a note mentioning since which version this is deprecated (e.g. `Since v1.0.0.`) and a note of what to use instead (or alternatively that it won't be replaced).
 
 ❌ Examples of **incorrect** code:
 
@@ -616,7 +616,7 @@ The description should end with a full stop.
  */
 ```
 
-### Use @returns if a function has a return value ✓
+### Use `@returns` if a function has a return value ✓
 
 Functions that return something should have an `@returns` statement in the documentation, followed by a description of the return value.
 The description should end with a full stop.
@@ -827,7 +827,7 @@ arr.forEach(item => {
 
 ### Use function declarations to reference functions by name
 
-Arrow functions require less boilerplate code than function declarations, especially if the function returns something directly, e. g. in one-liners.
+Arrow functions require less boilerplate code than function declarations, especially if the function returns something directly, e.g. in one-liners.
 For more complex functions, there is no significant difference.
 Arrow functions cannot be named and therefore have to be assigned to variables - much like function expressions.
 Function declarations are visually easier to differentiate from other variables than functions assigned to variables.

knowledge-base/adr/0027-versioning-strategy.md

@@ -23,14 +23,14 @@ We will keep this approach because:
 - It is very simple to have a fixed version for all packages.
   No need to monitor which packages have been changes to which extent.
 - It is easy to use/install the SDK, because all SDK parts have the same version.
-- It is done the same way by other monorepos like [nest](https://github.com/nestjs/nest) or [anguar](https://github.com/angular/angular).
+- It is done the same way by other monorepos like [nest](https://github.com/nestjs/nest) or [angular](https://github.com/angular/angular).
 
 The drawback of having new version without changes is taken into account for the simplicity.
 
 ## Decision Clients
 
 For the clients the situation is much less coupled than for core.
-Some services will update every two weeks (workflow) other every year (S/4 OnPremise).
+Some services will update every two weeks (workflow) other every year (SAP S/4HANA OnPremise).
 We will do versioning in the following way:
 
 - Major versions of clients aligns with major version of core.
@@ -40,7 +40,7 @@ We will do versioning in the following way:
 - Pipeline runs every two weeks and publishes only the changed clients with increased minor version.
 - Errors on the client layer are rare and in such a case we trigger a bump of all affected clients.
 
-This approach challenges the current release practice to a higer degree of automation.
+This approach challenges the current release practice to a higher degree of automation.
 
 ## Consequences
 

packages/generator/package.json

@@ -38,7 +38,7 @@
     "@sap-cloud-sdk/core": "^1.50.0",
     "@sap-cloud-sdk/generator-common": "^1.50.0",
     "@sap-cloud-sdk/util": "^1.50.0",
-    "@sap/edm-converters": "^1.0.21",
+    "@sap/edm-converters": "~1.0.21",
     "@types/fs-extra": "^9.0.1",
     "@types/glob": "^7.1.2",
     "execa": "^5.0.0",