jsapi - improvements for 3rd party consumers

[bmingles]

Improve jsapi for 3rd party consumers

CommonJS / non-browser module support The current jsapi is exposed as 2 ES modules that have dependencies on browser apis. Certain nodejs environments like Electron and Vscode extensions only support CommonJS. They also require polyfilling a few select browser apis to make jsapi function. It would be helpful to

1. Provide jsapi with zero browser dependencies
2. Provide this as multiple module types, namely es + commonjs

Dynamic download of jsapi We currently provide jsapis via urls on running DH instances. This is great since it ensures the jsapi is compatible with the server. It does, however, require some boilerplate scripting that is a bit cumbersome for a consumer.

Npm package It seems we could address all of the above in a single npm package.

• Handle downloading the appropriate api based on a server url
• Provide the appropriate module format for the consumer

[bmingles]

@niloc132 @mofojed I created this task to facilitate some discussion / thoughts on jsapi improvements based on recent experience developing a dh vscode extension.

[bmingles]

@niloc132 I investigated node support for h2c a bit. Here's my understanding:

• node fetch uses the undici package under the hood. Http2 is not the default, but it can be enabled. It does not support h2c. Also may still be considered experimental.
• fetch-h2 package supports h2c. There are some options for manual disconnection once requests are finished. Not sure how complicated this gets in practice