Duplicate remote `$ref` paths not resolved correctly

[SimonLudwigNeteleven]

Description

The command "yarn generate" should create all generated files including "types.gen.ts" without any issues.
The files are generated, but the response type of “B” is broken after the command finishes. This only happens, if both path references in the yaml file are the same for both paths. The first correct one wins, if both are the same.

This behavior breaks the type generation and I could only work around it, by making one path beginning with “http” instead of “https” in my project. This workaround is obviously more hack then a solution and works only for two paths maximum.
You can’t test the hack solution with “http” in stackblitz, because only “https” is allowed for the ref path, but you can reproduce the error.

Steps to reproduce the behavior

1. Go to my stackblitz example
2. open the terminal
3. enter “yarn”
4. enter “yarn generate”
5. inspect the generated files (types.gen.ts) in packages/test-api/navigation-api/src-gen

Expected behavior

AResponse and BResponse should be “(unknown)”.

Reproducible example or configuration

https://stackblitz.com/edit/vitejs-vite-6tvzvt?file=packages%2Ftest-api%2Fopenapi-spec%2Fnavigation-api.yaml

OpenAPI specification (optional)

No response

System information (optional)

No response

[bolt-new-by-stackblitz]

Start a new pull request in StackBlitz Codeflow.

• vitejs-vite-6tvzvt (Open reproduction)

[mrlubos]

Nice catch, thanks for reporting @SimonLudwigNeteleven!

[mrlubos]

@SimonLudwigNeteleven quick update, I found that this is most likely an issue with the underlying dependency https://github.com/APIDevTools/json-schema-ref-parser. Maybe there's a configuration for this, but a quick search didn't return anything.

For context, this is what happens internally. The first reference gets correctly bundled, for example:

{
  "type": "object",
  "properties": { "foo": { "enum": [], "type": "string" } }
}

while the second one produces this faulty reference.

{
  "$ref": "#/paths/~1a/get/responses/default/content/application~1json/schema"
}

I do plan to vertically integrate this tool eventually. Most people don't compose their schemas like this so it has not been reported before. Could you provide more context about your setup? How would you expect the remote reference to be resolved? Inline them or should they also create a reusable component and reference that?

[mrlubos]

@mmospanenko could you check the question above too?

[mmospanenko]

we have enough complicated flow, as source builds 300k lines yml file and has a lot of mistakes. I use as reference, giving ability to override some nodes ($ref) and as result we have template with tons of refs like your ("$ref": "#/paths/1a/get/responses/default/content/application1json/schema"). And these refs have own refs, and so on.

Now I use multi-file structure (from Redocly with their CLI) and it solves my case. So I have source file, it splits by files, then devs can add another copy of this file structure as 'overrides' folder, we prepare 'template' output file only with required paths, it merges and builds as result.

So TS in my case builds only from output, correct file, without complicated references. And this flow is better for my case now, not sure that TS generator should care about this, but it is definitely a bug from OAS perspective.