Is this still a valid task that anyone wants to pursue?
If it is, what would be the venue? Platform Team Workboards (Architecture Review Workboard) ? Front-end-Standards-Group ?
If not, then the status of this task should be realistically set to "declined".

See also T807: Investigate javascript library management options and T1017: Create RFC for library extraction (PHP & javascript) practices and T167041: Spike: Research JS UI libraries that can render in browser and server etc.

There's a dozen or so different libs around in the movement for Node.js or the browser. Taking one and improving it to become platform-agnostic, and, if not based on mediawiki.api, to become its replacement seems fine by me.

Having said that, I will note that most of these libraries are quite thin and imho barely justify their own existence. When all they do is take query parameters as a plain object, with a few sensible defaults, one might as well use Fetch (or jQuery.ajax) directly.

On the other hand, if there were to be an API that truly added its own value through removing abstractings and adding convenience with its own object representatins etc, that'd be a thing complex enough to want to have only one implementation of and share.

I'm unsub'ing since I don't plan to work on this myself, and what we have seems simple enough to maintain in its current form. Most of these libs see only one or two changes a year. But, as said, if someone were to put in the work to consolidate or expand this and not make things too complicated in the process, I'd be hapy to see MW adopt that library instead and transition our support to that.

Hey @Awesome_Aasim, I folded the T301217 task into this one.

Could you share with me what you like about mediawiki.api and what is missing on the list you sent so we could better understand what you are looking for?

Maybe if we have clarity on what is missing in the existing NPM packages we could help them improve.