Fix/explicit validation message zod

[XaaXaaX]

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]

🦋 Changeset detected

Latest commit: 6dcf884

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]

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]

@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]

@boyney123
i just raised a clean PR just for Parsing spec and resolving the $refs for parsed version #30

This PR now contains only zod validation