orval is able to generate client with appropriate type-signatures (TypeScript) from any valid OpenAPI v3 or Swagger v2 specification, either in yaml or json formats. 🍺
Fixed bug when faker attempted to create mocked data, the schema had recursive references, where the name of the schema was changed when sanitized to pascal case. The bug was fixed with the change in packages\mock\src\faker\getters\scalar.ts:176, but I found two checks to existingReferencedProperties in packages\mock\src\faker\getters\object.ts and packages\mock\src\faker\getters\combine.ts, so I thought I would proactively fix them too
Todos
[ ] Tests
[ ] Documentation
[ ] Changelog Entry (unreleased)
Steps to Test or Reproduce
Here is a simplified, obfuscated version of the json that caused the issue. The sanitation changed Foo.Bar.MainMenuItemDTO to FooBarMainMenuItemDTO, causing it to miss the check in existingReferencedProperties
I ran this json in the react query sample to confirm the bug, and the fix
Hmm, I saw that the yarn.lock file was updated and bumped a few version locally when I did yarn install. I discarded that. Not sure why it did, since I did not change any packages.
Status
READY
Description
Fixed bug when faker attempted to create mocked data, the schema had recursive references, where the name of the schema was changed when sanitized to pascal case. The bug was fixed with the change in
packages\mock\src\faker\getters\scalar.ts:176
, but I found two checks toexistingReferencedProperties
inpackages\mock\src\faker\getters\object.ts
andpackages\mock\src\faker\getters\combine.ts
, so I thought I would proactively fix them tooTodos
Steps to Test or Reproduce
Here is a simplified, obfuscated version of the json that caused the issue. The sanitation changed
Foo.Bar.MainMenuItemDTO
toFooBarMainMenuItemDTO
, causing it to miss the check inexistingReferencedProperties
I ran this json in the react query sample to confirm the bug, and the fix