Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error resolving $ref for property alongside top-level $ref #48

Closed
taicho opened this issue Sep 20, 2017 · 2 comments
Closed

Error resolving $ref for property alongside top-level $ref #48

taicho opened this issue Sep 20, 2017 · 2 comments
Labels

Comments

@taicho
Copy link

taicho commented Sep 20, 2017

All,

I'm having an issue resolving a reference. Having tested a couple scenarios, I was happy to see that providing a top-level reference and included some other properties alongside the $ref netted me a merged/combined object, for example:

Dereferencing this:

{
    "$ref":"http://someuri/myOtherSchema",
    "anotherProperty":"whatever"
}

Results in this (imagining myOtherSchema contains the added properties):

{
    "somePropertyFromMyOtherSchema": "misc",
    "anotherPropertyFromMyOtherSchema":"more",
    "anotherProperty": "whatever"
}

However, if I attempt to dereference the following:

{
    "$ref": "http://someuri/foo",
    "anotherProperty": {"$ref":"http://someuri/blah/some/field/value"}
}

It results in an error ('Error resolving $ref: http://someuri/blah/some/field/value'). It's worth noting that I am using a custom resolver and I changed the $ref urls for this post but removing the top-level $ref results in success i.e. my resolver is working as expected and in fact is a simple in-memory resolver. When this error happens the $ref mentioned in the error never even hits my resolver and its resolution is never attempted. Is having a top-level $ref alongside a property that points to a $ref expressly forbidden by the specification, is this a flaw or a feature of json-schema-ref-parser?

@taicho
Copy link
Author

taicho commented Sep 21, 2017

I'm closing this. This still fails when doing a straight dereference call but doing bundle -> dereference allows me to get the result I was looking for.

@JamesMessinger
Copy link
Member

JamesMessinger commented Sep 21, 2017

@taicho - Thanks for reporting this. I honestly never even thought about that use-case, so never tested for it. I'm going to re-open this issue as a reminder to fix this and add a test. I'm glad you found an acceptable workaround for the time-being though

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants