Closed paulRbr closed 3 years ago
Thanks for pointing that to me @philsturgeon I should have done that from the start. I think this patch is incorrect and I misunderstood the library internals.
Could you help me out?
Basically, I thought I could transparently use the resulting paths from the $Refs.paths()
function as inputs to the $Refs.get($ref)
function. But the documentation is clear: the get($ref)
function takes a “JSON Reference path, optionally with a JSON Pointer in the hash” and not a path/URL as I'm trying to do.
Maybe another solution would be to allow a new optional parameter to the $Refs.paths()
function which would return encoded file path list (instead of the current decoded path list).
What do you think?
Edit: I've pushed my new suggestion here
Edit2: I guess that's what the $Refs.values()
function is for. By return an object with decoded paths as keys and reference values as values. 🤦
I will close this PR for now as I guess I was trying to bypass the whole point of the existing $Refs.values()
function (that I missed). By returning an object with decoded paths as keys, this function is exactly what you should use when searching references from their original filesystem paths. Sorry @philsturgeon for the confusion!
The internal
_$refs
object stores all references path with an URL encoded value.However when using the public API of the $refs object most user will, most probably, expect to pass the decoded file path to all public methods (https://github.com/APIDevTools/json-schema-ref-parser/blob/master/docs/refs.md#methods)
This commit makes sure to search for URL encoded path value when the path is a file system path.