build: codegen to call clean on a per pkg basis

[jagpreetsinghsasan]

Commit to be reviewed

build: codegen to call clean on a per pkg basis

Primary Changes
---------------
1. Updated codegen scripts of all affected packages to include a global
   openapi-generator-ignore file
2. Created script to clean openapi folders generated by codegen for
   typescript-axios and kotlin

Secondary Changes
-----------------
1. Removed duplicated code generated previously when codegen clear wasn't
   enabled
2. Created openapi-generator-ignore file at project root for global ignore
   rules
3. Updated package.json of all affected packages, extensions and examples

Fixes #2736

Pull Request Requirements

• Rebased onto upstream/main branch and squashed into single commit to help maintainers review it more efficient and to avoid spaghetti git commit graphs that obfuscate which commit did exactly what change, when and, why.
• Have git sign off at the end of commit message to avoid being marked red. You can add -s flag when using git commit command. You may refer to this link for more information.
• Follow the Commit Linting specification. You may refer to this link for more information.

Character Limit

• Pull Request Title and Commit Subject must not exceed 72 characters (including spaces and special characters).
• Commit Message per line must not exceed 80 characters (including spaces and special characters).

A Must Read for Beginners
For rebasing and squashing, here's a must read guide for beginners.

[petermetz]

@jagpreetsinghsasan Huge diff, I might need to take multiple passes on reviewing this, apologies in advance. Quick findings on the first pass that I'd like to ask if you could maybe change up:

1. The tools/clear-openapi-codegen-folders.js script is not formatted (Prettier/ESLint)
2. Withing the logic of tools/clear-openapi-codegen-folders.js:
   2.1. There is a brittleness in it in terms of having the directory depth hard-coded in the globs. Instead of the patterns you have right now, I would pull the list of package directories straight from lerna.json and then do something like src/main/**/generated/ or similar (I'm making this as I go so it most likely need tweaks). My reasoning is that there were already multiple proposals for us to completely revamp the monorepo package directory structure from flat to hierarchical (tree structure) which would mean that the packages would no longer be at a fixed 2 deep from the project root. So if/when that change takes place, the current globs will break because it doesn't start from the package dir globs defined in lerna.json
3. If we no longer use the localized openapi-generator-ignore files (see all of them were reverted back to the default spat out by the generator) then we should just 1) delete them AND 2) ignore them in the centralized openapi-generator-ignore file that we have in the root, so that the package specific ignore files won't even get generated. This (in my opinion) would make it less confusing because there is no ignore file that isn't being used (meaning that the package local ignore files are being ignored but their existence would imply otherwise to begin with)
4. There are merge conflicts and for some reason not just in the yarn.lock file like the GitHub UI is suggesting; when I tried to rebase this to upstream/main it ran into hundreds of files being conflicted for some reason.

[jagpreetsinghsasan]

@petermetz all good suggestions!
I will fix/update the code and re-request for review asap

[jagpreetsinghsasan]

@jagpreetsinghsasan Huge diff, I might need to take multiple passes on reviewing this, apologies in advance. Quick findings on the first pass that I'd like to ask if you could maybe change up:

1. The tools/clear-openapi-codegen-folders.js script is not formatted (Prettier/ESLint)
2. Withing the logic of tools/clear-openapi-codegen-folders.js:
   2.1. There is a brittleness in it in terms of having the directory depth hard-coded in the globs. Instead of the patterns you have right now, I would pull the list of package directories straight from lerna.json and then do something like src/main/**/generated/ or similar (I'm making this as I go so it most likely need tweaks). My reasoning is that there were already multiple proposals for us to completely revamp the monorepo package directory structure from flat to hierarchical (tree structure) which would mean that the packages would no longer be at a fixed 2 deep from the project root. So if/when that change takes place, the current globs will break because it doesn't start from the package dir globs defined in lerna.json
3. If we no longer use the localized openapi-generator-ignore files (see all of them were reverted back to the default spat out by the generator) then we should just 1) delete them AND 2) ignore them in the centralized openapi-generator-ignore file that we have in the root, so that the package specific ignore files won't even get generated. This (in my opinion) would make it less confusing because there is no ignore file that isn't being used (meaning that the package local ignore files are being ignored but their existence would imply otherwise to begin with)
4. There are merge conflicts and for some reason not just in the yarn.lock file like the GitHub UI is suggesting; when I tried to rebase this to upstream/main it ran into hundreds of files being conflicted for some reason.

@petermetz

1. Done
2. I have updated the globs as how other scripts deal with similar paths
3. There is no way we can prevent the generation of per package openapi-generator-ignore files. The latest code update in this PR still includes them for the same reason. If having a post-cleanup script is fine (or any suggestions from your side), I can add that, to manually get rid of these per package generator ignore files (and can use the same script for doing pre and post cleanup just to not have lots of script files)
4. I have updated it, for some reason, something very weird was happening related to merge conflicts in a lot of files during rebase, but I have fixed them

[petermetz]

@jagpreetsinghsasan Huge diff, I might need to take multiple passes on reviewing this, apologies in advance. Quick findings on the first pass that I'd like to ask if you could maybe change up:

1. The tools/clear-openapi-codegen-folders.js script is not formatted (Prettier/ESLint)
2. Withing the logic of tools/clear-openapi-codegen-folders.js:
   2.1. There is a brittleness in it in terms of having the directory depth hard-coded in the globs. Instead of the patterns you have right now, I would pull the list of package directories straight from lerna.json and then do something like src/main/**/generated/ or similar (I'm making this as I go so it most likely need tweaks). My reasoning is that there were already multiple proposals for us to completely revamp the monorepo package directory structure from flat to hierarchical (tree structure) which would mean that the packages would no longer be at a fixed 2 deep from the project root. So if/when that change takes place, the current globs will break because it doesn't start from the package dir globs defined in lerna.json
3. If we no longer use the localized openapi-generator-ignore files (see all of them were reverted back to the default spat out by the generator) then we should just 1) delete them AND 2) ignore them in the centralized openapi-generator-ignore file that we have in the root, so that the package specific ignore files won't even get generated. This (in my opinion) would make it less confusing because there is no ignore file that isn't being used (meaning that the package local ignore files are being ignored but their existence would imply otherwise to begin with)
4. There are merge conflicts and for some reason not just in the yarn.lock file like the GitHub UI is suggesting; when I tried to rebase this to upstream/main it ran into hundreds of files being conflicted for some reason.

@petermetz

1. Done

2. I have updated the globs as how other scripts deal with similar paths

3. There is no way we can prevent the generation of per package openapi-generator-ignore files. The latest code update in this PR still includes them for the same reason. If having a post-cleanup script is fine (or any suggestions from your side), I can add that, to manually get rid of these per package generator ignore files (and can use the same script for doing pre and post cleanup just to not have lots of script files)

4. I have updated it, for some reason, something very weird was happening related to merge conflicts in a lot of files during rebase, but I have fixed them

@jagpreetsinghsasan Sorry for the slow response! Please re-request review next time!

1. and 2): Thank you very much!

There is no way we can prevent the generation of per package openapi-generator-ignore files.

What's wrong with ignoring the ignore files in the root ignore file like I just did on my local branch of your PR (see below)?

I have updated it, for some reason, something very weird was happening related to merge conflicts in a lot of files during rebase, but I have fixed them

Thank you for that as well!

[petermetz]

@jagpreetsinghsasan Please see my comment above^^

[jagpreetsinghsasan]

@jagpreetsinghsasan Please see my comment above^^

@petermetz , yes I was able to do it this way (It would have worked earlier too when I was trying, its just that the default globby options were not removing any files or folder with dot as the starting character ex .openapi-generator-ignore, so even after adding it to the global ignore file, it did nothing. I fixed it with onlyFiles: false in the globby options)
Now the local .openapi-generator-files are ignored and code works as intended

[petermetz]

@jagpreetsinghsasan Nice, thank you very much for the updates! LGTM