search

event-catalog / generator-openapi

OpenAPI generator for EventCatalog
Other
5 stars 1 forks source link

Fix/explicit validation message zod #27

Open XaaXaaX opened 2 months ago

XaaXaaX commented 2 months ago

Motivation

The fix resolve the technical exception while the consumers forget to add the mandatory service id while upgrading to version 2.0.0

changeset-bot[bot] commented 2 months ago

🦋 Changeset detected

Latest commit: 6dcf8842384c1cf2bd2b6dad238f06d98bdf4f41

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package | Name | Type | | ------------------------------- | ----- | | @eventcatalog/generator-openapi | Patch |

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

boyney123 commented 1 month ago

Hey @XaaXaaX

This ref stuff, from what I understand looking now we may need something like this https://github.com/APIDevTools/json-schema-ref-parser?

I'm looking at the output of the saveParsedSpecFile true test, and its still showing refs in the file, in fact nothing changed. I think this is happening

(AI Response I used)

The $ref fields you're seeing in your OpenAPI document are part of the OpenAPI specification itself, which defines how you refer to reusable components (like schemas) within the document. These are not internal YAML references (like &1 and *1), but rather are specific to OpenAPI for referencing schemas elsewhere in the document.

The noRefs: true option in js-yaml only controls whether YAML-specific references (anchors and aliases) are created. It doesn't modify the content of your document or remove any $ref fields that are part of your OpenAPI spec.

The stuff we are doing with the YML is removed YML references not the OpenAPI references, from what I understand like our AsyncAPI one we want to flattern the $ref values to be real values and I believe this would work https://github.com/APIDevTools/json-schema-ref-parser

Does that make sense?

XaaXaaX commented 1 month ago

@boyney123 i was aware of that, actually the parsed result contains the refs but some other metadata, the goal was not getting ride of $refs but keep the original file if the user wants it for any reason.

The first issue raised was about the x-parser-XXXXXX and other metadata that make the final spec verbose and hard to read by humain this was regarding asyncapi etc...

The $ref in a spec to me seems normal because you have the ref to components and it works this way (openApi, swagger or asyncapi) being parsed or not the refs will exist. there is no value to flattening an spec.

XaaXaaX commented 1 month ago

@boyney123 i just raised a clean PR just for Parsing spec and resolving the $refs for parsed version https://github.com/event-catalog/generator-openapi/pull/30

This PR now contains only zod validation