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.