Prepare @interledger/open-payments lib for use with manifest V3

[mkurapov]

Context

There are a few blockers when trying to use the @interledger/open-payments in the Web Monetization extension with the V3 manifest. The following should be investigated/completed before we fan support the library in the WM V3 extension.

Todos

• Replace axios in the library since XMLHttpRequest is unavailable in service workers (that the extension uses), which Axios relies on:

https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest_API
https://developer.chrome.com/docs/extensions/develop/migrate/to-service-workers#replace-xmlhttprequest

Possible solutions:

• ✅ using something like ky (http client built on top of fetch with hooks - beforeRequest, afterRequest …) (ky is the selected option as it provides a good API for hooks that allow us to sign requests in the SDK before making API calls)

• the option to pass an adapter when initializing the clients https://www.npmjs.com/package/@vespaiach/axios-fetch-adapter

• move to fetch - we will have to write our own interceptors

• Make schema validation optional in the SDK. This is for the following reasons:

Failed solution for schema validation:

• Update the @interledger/openapi library to not need to use $Ref parser library at runtime:

The $Ref parser library is using @jsdevtools/ono which is calling eval under the hood. For Manifest V2, I had to add the unsafe-eval option for the extension CSP (which we shouldn’t really ship with) and everything is working fine. If this option is removed we would not be able to load the schemas.
For Manifest V3, this is not going to be that straight-forward. eval is not allowed in Manifest V3:
The extension_pages policy cannot be relaxed beyond this minimum value. In other words, you cannot add other script sources to directives, such as adding 'unsafe-eval' to script-src. If you add a disallowed source to your extension's policy, Chrome will throw an error like this at install time

The $Ref parser can not resolve the schema path:
When moving to MV3, the library can not load the YAML schemas:
TypeError: Failed to construct 'URL': Invalid URL at Object.resolve (chrome-extension://kgdmilnbjkkipojajhbdebaljaadjjff/background/background.js:4271:37) at $RefParser. (chrome-extension://kgdmilnbjkkipojajhbdebaljaadjjff/background/background.js:1996:29) at Generator.next () at chrome-extension://kgdmilnbjkkipojajhbdebaljaadjjff/background/background.js:1925:71 at new Promise () at chrome-extension://kgdmilnbjkkipojajhbdebaljaadjjff/background/background.js:1921:12 at $RefParser.parse (chrome-extension://kgdmilnbjkkipojajhbdebaljaadjjff/background/background.js:1974:16) at $RefParser. (chrome-extension://kgdmilnbjkkipojajhbdebaljaadjjff/background/background.js:2055:28) at Generator.next () at chrome-extension://kgdmilnbjkkipojajhbdebaljaadjjff/background/background.js:1925:71 message : "Failed to construct 'URL': Invalid URL"
The library is using the URL object to construct the path and it is throwing when resolving the path: https://github.com/APIDevTools/json-schema-ref-parser/blob/12cb26a764b975de38143458d06972772609be76/lib/util/url.js#L31-L39
I’m not entirely sure why this is not happening when using Manifest V2 - my assumption is that in V3, the background script is a service worker and this is why it can not resolve the path even if we include polyfills for $Ref parser library

Unfourtunately, because the $Ref parser library, and the openapi validation libraries use ajv schema validation under the hood, (and because ajv uses unsafe eval), it is not a possible option to keep ajv in the openapi validation middleware that we use in the SDK.