References to existing but null values fail as missing

[pimterry]

When resolving a reference, if any value en route including the final value is null then resolution fails. This happens here:

json-schema-ref-parser/lib/pointer.ts

Line 96 in a5b3946

if (this.value[token] === undefined || this.value[token] === null) {

I think (not a JSON schema expert) this is incorrect. At the very least, it breaks parsing of some specs from https://github.com/APIs-guru/openapi-directory, including:

• https://github.com/APIs-guru/openapi-directory/blob/a52315437677ca06a8a152cb52aeb287f23f5323/APIs/rebilly.com/2.1/openapi.yaml#L22188 (referenced in a few places including https://github.com/APIs-guru/openapi-directory/blob/a52315437677ca06a8a152cb52aeb287f23f5323/APIs/rebilly.com/2.1/openapi.yaml#L14725)
• https://github.com/APIs-guru/openapi-directory/blob/a52315437677ca06a8a152cb52aeb287f23f5323/APIs/personio.de/personnel/1.0/openapi.yaml#L1624 (referenced e.g. in https://github.com/APIs-guru/openapi-directory/blob/a52315437677ca06a8a152cb52aeb287f23f5323/APIs/personio.de/personnel/1.0/openapi.yaml#L101)
• https://github.com/APIs-guru/openapi-directory/blob/a52315437677ca06a8a152cb52aeb287f23f5323/APIs/viator.com/1.0.0/openapi.yaml#L19100 (referenced all over the place, e.g. https://github.com/APIs-guru/openapi-directory/blob/a52315437677ca06a8a152cb52aeb287f23f5323/APIs/viator.com/1.0.0/openapi.yaml#L19102)

Why do these specs include reference to internal null fields? No idea, but as far as I'm aware it's valid to do so, and it's inconvenient that these specs are unparseable due to this issue.

This could be fixed by changing the check to not fail on null when dereferencing the last token in a path (before the last token, it should still be an error). I think undefined should still throw as it does now, because it's not a valid value in JSON, and so should never appear explicitly in a JSON schema (again, not an expert) unlike null.

I'm not totally sure if that change would have any other consequences though. This check was introduced by #153, and my best guess is that it was intended to handle the en-route (non-final) failure case, detecting it and creating an explicit error type for that as part of the error improvements there, but I can't be 100% sure there isn't another effect.

Happy to open a quick PR to make the change, if we can assume that's true and change this accordingly.

[jonluca]

Good call out and sorry for the delay here - this should be working like you said in v11.2.3

[pimterry]

Awesome, thanks @jonluca!

If you're working on this - any chance of updating https://github.com/APIDevTools/swagger-parser/ to use the latest version of this package?

It looks like that's currently pinned to 9.0.6, "to avoid circle bug" according to APIDevTools/swagger-parser@ef57642 (from @philsturgeon), I'm not sure exactly what that means but maybe it's resolved in later releases since then? It'd be great to see this updated to propagate the latest fixes here through that package too.