feat: enable openapi generator to include & exclude specific controllers

[aaqilniz]

At this point, the openapi generator has no way to include or exclude any API. This PR enables the openapi generator to receive three new options for users to control what APIs should be generated.

readonly (boolean): Passing this option would make the openapi generator create only GET endpoints.
exclude (regex - string): This enables the user to exclude particular APIs from the end result.
include (regex - string): This enables the user to include only some of the APIs and exclude everything else from the end result.

Checklist

• DCO (Developer Certificate of Origin) signed in all commits
• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• API Documentation in code was updated
• Documentation in /docs/site was updated
• Affected artifact templates in packages/cli were updated
• Affected example projects in examples/* were updated

👉 Check out how to submit a PR 👈

[coveralls]

Pull Request Test Coverage Report for Build 8358248924

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 55.371%

---

Totals
Change from base Build 8102944384:	0.0%
Covered Lines:	9563
Relevant Lines:	12457

---

💛 - Coveralls

[aaqilniz]

Hi, @dhmlau Can you please have a look at this PR and suggest to me any changes/improvements required?

[samarpanB]

How about we provide an attribute in @post , @patch, @get, @delete, @put decorators to hide/unhide APIs from openapi generation ? Eventually, that's the place from where openapi spec is generated. Ideally, thats the better place to have a flag or a config. Thoughts ?

[aaqilniz]

How about we provide an attribute in @post , @patch, @get, @delete, @put decorators to hide/unhide APIs from openapi generation ? Eventually, that's the place from where openapi spec is generated. Ideally, thats the better place to have a flag or a config. Thoughts ?

Do you mean the generator would generate the routes but the APIs would not be accessible?
I think if someone would like to generate only GET APIs (readonly), for example, the generator should not generate other routes at all.

[samarpanB]

How about we provide an attribute in @post , @patch, @get, @delete, @put decorators to hide/unhide APIs from openapi generation ? Eventually, that's the place from where openapi spec is generated. Ideally, thats the better place to have a flag or a config. Thoughts ?

Do you mean the generator would generate the routes but the APIs would not be accessible? I think if someone would like to generate only GET APIs (readonly), for example, the generator should not generate other routes at all.

I think I am misunderstanding this PR. Which cli command is this referring to ?

[aaqilniz]

How about we provide an attribute in @post , @patch, @get, @delete, @put decorators to hide/unhide APIs from openapi generation ? Eventually, that's the place from where openapi spec is generated. Ideally, thats the better place to have a flag or a config. Thoughts ?

Do you mean the generator would generate the routes but the APIs would not be accessible? I think if someone would like to generate only GET APIs (readonly), for example, the generator should not generate other routes at all.

I think I am misunderstanding this PR. Which cli command is this referring to ?

This PR is related to lb4 opneapi command.