error: The $ref targets root is not found: #330

abdulkareemnalband · 2019-03-29T10:42:59Z

dtsgen throws error for http://adaptivecards.io/schemas/adaptive-card.json

The $ref targets root is not found: #/definitions/AdaptiveCarD

horiuchi · 2019-04-01T03:07:31Z

the command of npx dtsgenerator --url https://adaptivecards.io/schemas/adaptive-card.json return corret result.

What do you do?

abdulkareemnalband · 2019-04-01T06:01:23Z

@horiuchi thans for reply.
yes above command works (I did'n know about above syntax)
what i did was

create a new npm project
copy json schema to folder
npm install --save dtsgenerator
ran node_modules/.nin/dtsgen schema.json
I get the error

@horiuchi If you think this issue is Invalid then please close this
Thanks again for your wonderful tool

adriengibrat · 2019-10-26T14:05:15Z

@horiuchi you should close this issue, it was invalid ;)

horiuchi · 2019-10-28T03:34:20Z

Actually this behavior is not invalid.
This is due to the slight difference between getting the schema using --url and getting the schema from a local file.
It's essentially due to the schema file, but I want it to work in either case.

quantizor · 2020-04-03T21:54:22Z

@horiuchi just ran into this trying to process a local openapi v3 yaml. would love to use the tool

iansan5653 · 2020-05-12T17:57:11Z

I get this error when I have a response component with an empty content (ie only headers).

0gust1 · 2020-09-24T16:03:31Z

Just ran into this issue too !
I was making changes to an existing API. dtsgen was running fine before.

I'm investigating... in my case, it seems linked to the content-type value of the response definition.
My new response is an application/octet-stream one.
If I change it to text/XXX (literaly) or text/octet-stream or application/json, dtsgen doesn't complain anymore.

0gust1 · 2020-09-25T07:53:47Z

Some news : it was on my side ! The response mapped on a schema that contained a oneOf, branching between a text format and binary format.

This "branching" is better done at response definition level, like this : https://swagger.io/docs/specification/describing-responses/#media-types
Maybe the dtsgen output could be a bit more specific about possible cause ? (I don"t know if it's possible, and I'm already glad to have this tool, thanks !)

soprandi · 2021-03-15T10:10:28Z

Hi, I've a similar issue but looks related to the remote reference $ref is pointing to a document located in another folder.
my yaml $ref looks like this
$ref: '../common/responses.yaml#/responses/resp500' according with https://swagger.io/docs/specification/using-ref/

Any ideas?
using a URL instead of a path seems to work

Thanks for any suggestion... i really like this generator
many tanks

JBBianchi · 2021-04-29T13:00:38Z

Hello, I'm facing the same error when trying to parse JSON Schema of the serverless workflow specification.

I downloaded them locally and tried to process workflow.json (the "entry point") but ended up with those errors:

> dtsgen --out types.d.ts schema/**/*.json
Error: The $ref targets root is not found: #/definitions/eventdef
The $ref targets root is not found: #/definitions/function
The $ref targets root is not found: #/definitions/retrydef

(related to #414 #321 ?)

I also tried to process the schema remotely and I think there is a mixup between $id and $ref:

> dtsgen --url https://raw.githubusercontent.com/serverlessworkflow/specification/main/schema/workflow.json --out types.d.ts 
Error: Fail to fetch the $ref target: https://serverlessworkflow.org/core/common.json#/definitions/metadata, Error: Error on fetch from url(https://serverlessworkflow.org/core/common.json#): 404, <!DOCTYPE html> ...

I looks like it uses a relative url from $id (? not even sure because /0.6/ is lost) of the entry schema 'instead of' a relative url of the one provided by --url. But this is probably another issue than the one discussed here.

horiuchi · 2021-05-13T08:53:09Z

@JBBianchi
I looked into this matter: https://github.com/serverlessworkflow/specification/tree/main/schema

As a result, the file linked from workflow.json was not reading correctly because of its format which is not expected for JSON Schema. For example, in the root of events.json, there is an unexpected property events. We are trying to reference this path from workflow.json, but the parse of events.json ignores this path, resulting in an error.

The reason for the Fail to fetch the $ref target is that if you reference another file with $ref and it is a relative reference, it will be treated as a relative reference to the original file's $id URL.
Since the $id of workflow.json is https://serverlessworkflow.org/core/workflow.json,
when resolving references to common.json#/definitions/metadata,
the base URL will be https://serverlessworkflow.org/core/
and the result will be https://serverlessworkflow.org/core/common.json#/definitions/metadata.
However, the file does not exist in this URL, so fetch is giving an error.

JBBianchi · 2021-05-13T10:28:59Z

@horiuchi

First, thanks for your feedback. Here are my remarks:

As a result, the file linked from workflow.json was not reading correctly because of its format which is not expected for JSON Schema. For example, in the root of events.json, there is an unexpected property events. We are trying to reference this path from workflow.json, but the parse of events.json ignores this path, resulting in an error.

It's not strictly compliant but it's still a valid JSON Schema, they can have as many extra properties is still be valid per say. As it is, events.json cannot really be used as an entry point. But, it can be referenced, like it is in workflow.json, explicitly pointing to the property in the document.

The reason for the Fail to fetch the $ref target is that if you reference another file with $ref and it is a relative reference, it will be treated as a relative reference to the original file's $id URL.
Since the $id of workflow.json is https://serverlessworkflow.org/core/workflow.json,
when resolving references to common.json#/definitions/metadata,
the base URL will be https://serverlessworkflow.org/core/
and the result will be https://serverlessworkflow.org/core/common.json#/definitions/metadata.
However, the file does not exist in this URL, so fetch is giving an error.

I did understand the cause and it's indeed a valid way to see things. But, the specs isn't very specific on that topic, the top-level $id MAY be used as a base URI for the $refs of the documents but it's implementation specific. Maybe it would be a good idea for try the relative URL from $id first and if it fails, try it relative from the 'input URI' ?

In the end, I found a way to achieve what I wanted. I used json-schema-ref-parser to merge all schemas in one and generated the TS from there. It's probably not the most robust approach but it works for that use-case.

horiuchi · 2021-05-14T01:47:15Z

@JBBianchi
Thank you for your useful comments!

As a result, the file linked from workflow.json was not reading correctly because of its format which is not expected for JSON Schema. For example, in the root of events.json, there is an unexpected property events. We are trying to reference this path from workflow.json, but the parse of events.json ignores this path, resulting in an error.

It's not strictly compliant but it's still a valid JSON Schema, they can have as many extra properties is still be valid per say. As it is, events.json cannot really be used as an entry point. But, it can be referenced, like it is in workflow.json, explicitly pointing to the property in the document.

Yes, I know. But In my implementation, the extra properties are ignored. So if you try to reference it later, it will be treated as if it doesn't exist.

I did understand the cause and it's indeed a valid way to see things. But, the specs isn't very specific on that topic, the top-level $id MAY be used as a base URI for the $refs of the documents but it's implementation specific. Maybe it would be a good idea for try the relative URL from $id first and if it fails, try it relative from the 'input URI' ?

Yes, so if '$id' does not exist, the 'input URL' is treated as the Base URI.
As far as I'm concerned, I'm assuming that the URL in '$id' is the actual hosting URL.

In the end, I found a way to achieve what I wanted. I used json-schema-ref-parser to merge all schemas in one and generated the TS from there. It's probably not the most robust approach but it works for that use-case.

I thought I should reconsider using the json-schema-ref-parser to replace the original implementation for '$ref' resolution. Because the '$ref' resolution is really complicated.

alexkar598 mentioned this issue May 24, 2020

Fixes ref to empty response causing an error (Error: test The $ref tarrgets root is not found: #/components/responses/created) #416

Merged

horiuchi added the enhancement label Jan 5, 2021

JBBianchi mentioned this issue Apr 30, 2021

Is this the right approach ? serverlessworkflow/sdk-typescript#73

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

error: The $ref targets root is not found: #330

error: The $ref targets root is not found: #330

abdulkareemnalband commented Mar 29, 2019

horiuchi commented Apr 1, 2019

abdulkareemnalband commented Apr 1, 2019

adriengibrat commented Oct 26, 2019

horiuchi commented Oct 28, 2019

quantizor commented Apr 3, 2020

iansan5653 commented May 12, 2020 •

edited

Loading

0gust1 commented Sep 24, 2020 •

edited

Loading

0gust1 commented Sep 25, 2020

soprandi commented Mar 15, 2021

JBBianchi commented Apr 29, 2021 •

edited

Loading

horiuchi commented May 13, 2021

JBBianchi commented May 13, 2021

horiuchi commented May 14, 2021

error: The $ref targets root is not found: #330

error: The $ref targets root is not found: #330

Comments

abdulkareemnalband commented Mar 29, 2019

horiuchi commented Apr 1, 2019

abdulkareemnalband commented Apr 1, 2019

adriengibrat commented Oct 26, 2019

horiuchi commented Oct 28, 2019

quantizor commented Apr 3, 2020

iansan5653 commented May 12, 2020 • edited Loading

0gust1 commented Sep 24, 2020 • edited Loading

0gust1 commented Sep 25, 2020

soprandi commented Mar 15, 2021

JBBianchi commented Apr 29, 2021 • edited Loading

horiuchi commented May 13, 2021

JBBianchi commented May 13, 2021

horiuchi commented May 14, 2021

iansan5653 commented May 12, 2020 •

edited

Loading

0gust1 commented Sep 24, 2020 •

edited

Loading

JBBianchi commented Apr 29, 2021 •

edited

Loading