CHORE[DEPENDENCIES]: bump swagger-parser => 2.0.22

[codymikol]

this fixes a bug where the parser would return
null when missing parameters rather than reporting
some useful error.

Fixes N/A

This bumps the swagger-parser library form 2.0.20 to 2.0.22, this fixes a bug in the parser library that would cause openapi-generator to mysteriously fail when parameters are not defined in your api spec

My original issue was opened over here: #7453 , but my fix just prevented openapi-generator from throwing a null pointer exception. This update fixes the underlying problem to that issue.

This is the specific PR that fixed that issue: swagger-api/swagger-parser#1410 (thank you, I appreciate you)

2.0.22 changes: https://github.com/swagger-api/swagger-parser/releases/tag/v2.0.22

2.0.21 changes: https://github.com/swagger-api/swagger-parser/releases/tag/v2.0.21

Changes Related to this version bump

The petstore examples have a new parameter relating to: Add extension to keep track of original swagger version in PR #1374

The InlineModelResolver fixStringModel method needs to be adjusted per Fix for Empty and Blank query parameters issue PR - #1376 as it will no longer return null values for empty url parameters, but rather empty strings.

There is also a test that essentially just proves the same getExample method will return null, I have changed the test to instead just assert the returned value is an empty string. I do think that this is an unnecessary test for this project as it is essentially testing a 3rd party dependency and would be fine with removing it based on feedback.

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• If contributing template-only or documentation-only changes which will change sample output, build the project beforehand.
• Run the shell script ./bin/generate-samples.shto update all Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master. These must match the expectations made by your contribution. You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*. For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

[codymikol]

From the looks of the CI, there will be quite a bit more work than just bumping the version number :/

[codymikol]

It appears all of these failing tests come from changes in 2.0.21 : (

[codymikol]

It seems to me that there was some workaround in openapigenerator for string values having escape characters baked into them that is no longer the case, I have an ugly fix that makes most of the tests pass, I'll try and clean it up farther.

[codymikol]

There is a test emptyExampleOnStringTypeModels that seems to assert the swagger-models schema object has a null value for getExample(), which is no longer the case after this update. For the time being I have changed it to assert that the getExample() is an empty string, but seeing as this is testing outside the scope of openapi-generator, I think we can just go ahead and remove this test. Feedback on that would be great.

[codymikol]

: / It looks like all CIs are passing except circleci, but circleci won't let me look at the results of the build unless I give it read / write access to my repos and I'm not too keen on that.

EDIT: Made a burner bitbucket account, looks like it timed out. I'll just rehash the commit I suppose...

EDIT: Looks like we’re all good to go!

[jimschubert]

lgtm
the test assertion just needs to be flipped

pinging @OpenAPITools/generator-core-team for additional set of eyes, as I know there was some reason we weren't bumping to 2.0.21 but can't recall what it was.

[jimschubert]

@sebastien-rosset I see you added this to swagger-parser, but it doesn't seem to be consumed anywhere.

Do you need to create a follow up to consume this as mentioned in #6290?

Limitation: due to issue swagger-parser #1369, achieving OAS compliance is not possible when the input document uses the OAS 2.0 schema. For OAS 2.0 documents, the legacy behavior should be used by setting the disallowAdditionalPropertiesIfNotPresent CLI option to true.

[sebastien-rosset]

yes, there needs to be a follow up. Actually even better would be to ensure the 2.0 parser is converting additionalProperties properly.
With x-original-swagger-version, at least we know the source is 2.0, but if the converter is not converting properly to 3.0 (and retaining the semantics), it's still going to be a problem.