parsers/resolvers get partial file URL for json-pointer refs

[eliranmal]

description

when a schema definition includes $refs with (non-relative) json-pointer values, any parsers/resolvers hook functions (namely, read(), parse(), canRead() and canParse()) are called with a file info object that has a partial URL.

"partial URL" here refers to the original json-pointer URI, stripped of its anchor segment, for example, http://mydomain/schema#/inner would become http://mydomain/schema.

this behavior is the same for both bundle() and dereference() (other API methods had not been tested).

it makes handling of such json-pointer $refs harder when writing custom resolvers/parsers (my use case is returning 'mock' or 'placeholder' schemas for some user defined $ref matches in a generated bundle).

steps to reproduce

1. create a schema definition with a json-pointer $ref, e.g.:

   const mySchema = {
     "$ref": "http://mydomain.com/schema#/inner"
   };

2. implement any of the custom resolvers/parsers hook functions, and test the file.url value:

   parser.bundle(mySchema, {
     resolve: {
       myResolver: {
         order: 1,
         canRead: (file) => {
           console.log(file.url); // -> http://mydomain.com/schema
           return true;
         },
       },
     },
   });

see a runnable demo on runkit.

expected result

the file info object's url field should hold the $ref value as found in the original schema definition.

actual result

the file info object's url field hold a partial value, in case of json-pointer URI values - the anchor segment is stripped out.

workarounds

• i think one can retrieve the last value of parser.$refs.paths() and have the full URL for a specific invocation of parse(), canRead() etc., but that's quite brittle - as the $refs.paths() API may change in future versions, and also not very pure (in a FP sense).
  i haven't tested this approach, though. apparently, this approach doesn't work; parser.$refs.paths() returns the same stripped path.

[eliranmal]

by the way, #47 seems interestingly aligned with my real use case. its resolution may render this issue redundant.

[JamesMessinger]

Hi @eliranmal. Sorry for taking so long to respond.

This behavior is by design. When a JSON Reference ($ref) contains a hash character (#), the part before the hash indicates the resource that's being referenced, and the part after the hash is a JSON Pointer that indicates a specific part of that resource. The "file info" object that's passed to the hook functions represents the entire file, not just a part of it, which is why the url property doesn't contain the hash portion. The job of functions like read() and parse() is to read/parse the entire resource. After that, it's up to json-schema-ref-parser to crawl the parsed resource and find the specific part that the $ref points to.

[eliranmal]

@BigstickCarpet - i get it, i thought it would be easier for my use-case if the hash was passed as well.

i'll follow #47 and see if it matches my needs.

thanx :)