Reduce disk footprint of dependencies

[TimvdLippe]

When analyzing the disk sizes of various dependencies in the node_modules of Chrome DevTools, I discovered core-js-pure which is our 3rd largest dependency at 6.9MB on disk. It appears that aria-query is the only package having a transitive dependency on core-js-pure via @babel/runtime-corejs3.

This package appears to be supporting Node 6, but Node 10 has recently gone EOL. Could you update your Node version compatibility to support those versions supported by Node itself (https://nodejs.org/en/about/releases/) and drop your usage of @babel/runtime-corejs3? Looking at the implementation of this package, that seems feasible, as it doesn't use very many features that Node 12+ don't support. Hence I think dropping corejs3 usage is feasible.

[eps1lon]

This package appears to be supporting Node 6, but Node 10 has recently gone EOL.

I agree there but dependent packages support older node versions as well. Most prominently eslint-plugin-jsx-a11y. So if we would drop node 10 then those packages would no longer be able to receive updates.

So the quest for node 12 has to start at the top.

[TimvdLippe]

So if we would drop node 10 then those packages would no longer be able to receive updates.

I suppose that the packages have to update at that point? To my knowledge, this commonly happens where a dependency drops Node support up to a certain version and publishes a major version. Dependents then have to catch up at some point, which generally happens relatively quickly. Especially as Node 10 is EOL, I think that should be fairly straightforward?

[eps1lon]

I suppose that the packages have to update at that point?

Yes. But what if they can't do that for one reason or another? That's why I was suggesting to communicate with downstream package maintainers first.

[TimvdLippe]

That seems to be a problem for the downstream package to resolve, if they would not be able to keep up with the Node releases. But I will reach out to eslint-plugin-jsx-a11y first I suppose to let them drop Node <12 support.

[eps1lon]

That seems to be a problem for the downstream package to resolve, if they would not be able to keep up with the Node releases.

We'd like to get updates to as many people as possible. If you care more about install size on your machine than downstream packages, then I'd suggest you go ahead and fork aria-query.-

[ljharb]

Node platform support should be irrelevant, and capriciously dropping support for a node version when unnecessary is user-hostile.

Disk space is infinite and free, and should simply not be a consideration unless all other constraints are equal.

[ljharb]

All that said, I'm sure this package could look into altering its code/babel settings if the maintainers wished to and reduce its installed size without dropping platform support - that's a tradeoff the maintainers here would need to make.

[TimvdLippe]

Disk space is infinite and free, and should simply not be a consideration unless all other constraints are equal.

Sadly our network bandwidth and disk usage is an important consideration for us, given the amount of times we download and compile Chromium every single day. This is a non-trivial amount of traffic that we have to deal with, where even saving a couple of MBs in a single package can result in major improvements over time.

All that said, I'm sure this package could look into altering its code/babel settings if the maintainers wished to and reduce its installed size without dropping platform support - that's a tradeoff the maintainers here would need to make.

That would work for us 😄 Maybe to make it clear, I didn't want to needlessly push churn on users. I mostly thought: if versions of Node are no longer supported, dropping support for them seems reasonable for an NPM package. From that point of view, there would be a way forward.

Let me know if you would like to investigate whether removal/reduction of Babel usage would be desirable for this package and happy to contribute a PR for that.

[eps1lon]

I think it's better to release a breaking change that is getting rid of some of the modern code/types (I suspect most of the map/set iterable usage is unnecessary) instead of releasing a breaking change that bumps the minimum node version. Downstream packages can adjust their code consuming aria-query but they can't just bump the minimum node version.

@TimvdLippe I can't make any statement about the timeframe here. Maybe you can convince your company to sponsor this work if this is such an important consideration for you.

[TimvdLippe]

I am happy to contribute the necessary fixes to reduce the Babel usage. Let me know what your preferred solution is and then I can work on a PR.

[eps1lon]

I am happy to contribute the necessary fixes to reduce the Babel usage. Let me know what your preferred solution is and then I can work on a PR.

I would start by trying to convert all the Map types to plain objects and just using Object.keys. That should get rid of most of the polyfills and iterator protocol usage. I think we may be able to keep the original interface if we convert the new objects to maps with new Map(Object.keys(whatWasPreviouslyAMap).map((key) => [key, whatWasPreviouslyAMap[key]])).

And spread syntax can be converted to Array.prototype.concat e.g.

aria-query/src/roleElementMap.js

Lines 19 to 22 in 38f1759

	[
	...role.baseConcepts,
	...role.relatedConcepts,
	]

can become role.baseConcepts.concat(role.relatedConcepts).

[TimvdLippe]

I took a stab at it and opened #162. However, it still has several require for the map-related code. Also, some code I wasn't able to convert, as it was using type aliases of strings, yet Flow didn't allow me to iterate over these objects.

Given that the babel usage is still there on runtime, I am not sure whether it makes sense to only do these, as more code would have to be converted. It would be a breaking change to move from Map<K,V> to Record<K,V> I suppose, but that would allow you to remove several other require's. That should be fairly straighforward by removing the convertToMap function and return the object directly.