FWIW, I think m3api includes most of the features listed above – the biggest difference being that it’s a library for the Action API and I have no plans to support the REST API there.

In T353139#9396775, @LucasWerkmeister wrote:

FWIW, I think m3api includes most of the features listed above – the biggest difference being that it’s a library for the Action API and I have no plans to support the REST API there.

Oh nice, I'll have a look!

There are a number of existing JavaScript clients for the MediaWiki API under https://www.mediawiki.org/wiki/API:Client_code#JavaScript.

It might be worth improving one of those. Some of them have non-trivial adoptoin in the npm ecosystem. It might be high reach to expect ours to "take over" the market, and perhaps wasteful to compete. There may also be various bits of experience (at least for the Action API clients) in those clients that we can at least learn from to avoid repeating past mistakes.

If the main objective is isomorphic portability between Deno/Node/browser, we'll probably want to avoid any runtime dependencies and instead use the modern Fetch API. fetch() is built-in to Deno and (since the last LTS) also in Node.

Note that in addition to these various unofficial API clients on npm, we do actually maintain 1 offical client already as part of the MediaWiki core repository for client-side use in browsers, the mediawiki.api module. Unless there are specifically incompatible signatures you're looking to adopt, it might be worthwhile to use this as the starting point. That way, we don't end up maintaining two separate ones.

For example, we could improve the one in MediaWiki core to become isomorphic, and then publish to npm from there (like we do for wdio-mediawiki`). That'd likely be easier than maintaining it elsewhere and trying to bring it into MW alongside a competing implementation (unless the interface has limitations that would stand in the way?).

TODO: review https://www.mediawiki.org/wiki/API:Client_code#JavaScript

We have client side code that MediaWiki's UI uses to make calls to the API, but it's not really usable outside the browser, and outside the context of MediaWiki's client side framework. Factoring it out, modernizing it, and making it usable in node.js would perhaps be a viable approach.