fix(security): swapping out jsonpath-plus for jsonpath in v20

[erunion]

🚥 Towards readmeio/api#969

🐳 Context

The v20 series of this library, which v6 of api notably uses, has a vulnerability in its dependency on jsonpath-plus.

We have already upgraded jsonpath-plus in later releases of oas to resolve this problem but because those newer versions require Node 18+ and v20 of oas is still on Node 14+ we can't bump it. We have also resolved this problem in the still-in-beta release of api in the v7 release but due to a remaining list of issues to resolve and time constraints we can't pull that out of its next channel.

Instead I'm reaching for the last option here and it's to fix the problem in our v20 series directly.

🧰 Changes

Because I can't upgrade jsonpath-plus within v20, as that would be a breaking change, I'm instead opting for the shittier solution of swapping it out for jsonpath. jsonpath has no dependencies, has not been updated in 4 years, but it does not have any open vulnerabilities and can mostly handle the our analyzer queries.

With the move here to jsonpath we lose the ability to do backreference parent and property queries, which unfortunately means that the query results will be a little different but the queries still generally point to the same place.

I don't really like this solution because jsonpath is severely limited when compared to jsonpath-plus but given that oas@20 is still in use in api@6 and rdme@8¹ this should at least stem the tide of us receiving reports about it showing up in npm audit.

🧬 QA & Testing

Check out the test assertion changes for the query result differences. They're still mostly the same, just slightly different.

Footnotes

1. rdme@8 has long been deprecated but according to NPM it's still received 47k downloads in the last 7 days. 🙃 ↩

[erunion]

jsonpath doesn't support @property.match queries.

[kanadgupta]

happy with this! only feedback: can you rename the v20 branch to oas-v20 or something so it's explicitly clear which subpackage it's for?

rdme@8 has long been deprecated but according to NPM it's still received 47k downloads in the last 7 days. 🙃

regarding the above, rdme@9 has only been out since december and isn't actually deprecated on npm so i'm not too worried. it makes sense why we're doing this for api@6, but rdme@9 was designed to be a seamless upgrade for nearly all rdme@8 users. i'm pretty opposed to backchanneling any changes for rdme@8, that's why we maintain rdme@9 in the first place. writing a good deprecation message for rdme@8 and earlier on npm should help get those numbers up.