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

Pascal regex with ending digit error #120

Open
r00ta opened this issue Nov 11, 2022 · 2 comments
Open

Pascal regex with ending digit error #120

r00ta opened this issue Nov 11, 2022 · 2 comments

Comments

@r00ta
Copy link

r00ta commented Nov 11, 2022

This regex for PascalCase is not allowing trailing numbers (see this error) is there a specific reason for that or is it possible to change the regex to allow this pattern?

Thanks

@manstis
Copy link

manstis commented Nov 14, 2022

This issue seems to be opening a wider reaching concern of API versions.

If we rename the type to something like BridgeResponseV2DTO we are still hit with the Pascal Case violation.

We'd (hopefully) all agree BridgeResponseVTwoDTO is not a good name.

The problem is we're generating a single OpenAPI definition for both API versions and as such we cannot re-use the simple form BridgeResponse as the types are defined at the root (components\schemas) level of the OpenAPI file and not "per path" (paths\<path>\verb where <path> contains the version information).

What is the proposal for different API versions? Multiple OpenAPI definition files? Does AppServices support that?

@r00ta
Copy link
Author

r00ta commented Nov 14, 2022

This issue seems to be opening a wider reaching concern of API versions.

If we rename the type to something like BridgeResponseV2DTO we are still hit with the Pascal Case violation.

We'd (hopefully) all agree BridgeResponseVTwoDTO is not a good name.

The problem is we're generating a single OpenAPI definition for both API versions and as such we cannot re-use the simple form BridgeResponse as the types are defined at the root (components\schemas) level of the OpenAPI file and not "per path" (paths\<path>\verb where <path> contains the version information).

What is the proposal for different API versions? Multiple OpenAPI definition files? Does AppServices support that?

As per internal chat we proposed that the service could have one independent openapi file for each version of the backend api, and the sdk team could generate a brand new sdk for each openapi file. Let's say a smart events v1 and smart events v2 artifacts in this list - ready to be downloaded and used
Screenshot from 2022-11-14 09-45-06

cc @dimakis

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

No branches or pull requests

2 participants