json-refs
json-refs copied to clipboard
Filter 'relative' does not behave as expected
According to the API documentation, the filter
option allows us to specify what type of references we want to be resolved. In a previous version of this library (2.1.6
), it was possible to do:
const options = {
filter: 'relative',
loaderOptions: {
processContent: (res, cb) => {
cb(null, yaml.safeLoad(res.text));
},
},
};
resolveRefs(root, options)
Resulting in only relative
references being resolved, meaning that any other references (like remote
references) would remained unresolved.
However, in the latest version of this library this is no longer possible, given that all reference types that are considered "remote" (both relative
and remote
, see here) are forced to be fully resolved (see here).
It would be great if this filter
option could be restored to allow developers decide which reference types should be resolved and which not.
Please let me know if this issue seems interesting to you. I would be happy to contribute with a fix. Cheers!
Here is an example:
Input
{
"a": "./b/c.yaml",
"d": "https://my.domain.com/e/f.yaml
}
Expected Output
{
"a": {
"b": "c"
},
"d": "https://my.domain.com/e/f.yaml
}
Actual Output
{
"a": {
"b": "c"
},
"d": {
"e": "f"
}
}
Update March 11th
I just submitted a PR that includes a unit test that showcases this issue (see #155). While I was writing this unit test I realized that this example is actually not accurate and is not valid to reproduce the issue. The problem only applies to the remote references contained by any relative reference. Therefore, a more appropriate example would look like this:
Input
Root json file
{
"a": {
"$ref": "./b/c.json"
}
"d": {
"$ref": "https://my.domain.com/e/f.json"
}
}
File ./b/c.json
{
"b": {
"$ref": "https://my.domain.com/c.json"
}
}
Expected Output
{
"a": {
"b": {
"$ref": "https://my.domain.com/c.json"
}
}
"d": {
"$ref": "https://my.domain.com/e/f.json"
}
}
Actual Output
{
"a": {
"b": {
"c": "some dummy content"
}
}
"d": {
"$ref": "https://my.domain.com/e/f.json"
}
}
I hope this example makes more sense @whitlockjc
Thanks for the reproduction, I didn't realize we broke this. I will get on this.
@whitlockjc do you have an ETA for the fix? Thanks in advance.