Reduce disk footprint of dependencies
TimvdLippe opened this issue · comments
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.
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.
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?
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.
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.
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.-
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.
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.
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.
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.
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 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
can become
role.baseConcepts.concat(role.relatedConcepts).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.
According to Node.JS release page, even Node 12 is approaching EOL. Seems not useful to keep supporting node down to version 6 IMHO.
The Javascript echosystem moves fast (perapps too fast? But that's another story :)), packages need to catch up. We should discourage as strongly as possible people from using unsecure software versions.
So yeah, huge +1 for requiring at least node 12.x!
EOL is irrelevant. Just because node drops support for a version doesn’t mean people stop using it, and more importantly, doesn’t mean the equivalent web browsers stop being used.
@ljharb if someone uses something that is EOL he/she is, and should be, completely on his/her own. It cannot be expected that a library supports EOL software versions... If a developer implements anything leveraging EOL software versions, well, he/she would have to ask him/herself many questions :)
With regards to browsers is a completely different story, I agree. In fact, I am talking about node specifically
On their own from the platform, yes. Not from everyone on the planet.
@ljharb seriously? If a node version is no longer maintained security issues might be found out at any time, without any chance of them getting patched. You would be extremely irresponsible for using such a software version; given the low entry-barrier within the node echosystem, package maintainers should be responsible for enforcing best practices! Not to mention that this attitude is preventing the node echosystem to evolve... Yeah, we still cannot have treeshaking in backend node applications, as almost no libraries are designed with such an approach in mind.
This being said, it's obvious we won't reach any consensus on the way to proceed... @jessebeach what do you think as a maintainer?
I'd be happy to contribute, but not to support deprecated, end-of-life, and definitely legacy node versions.
Again, those node versions are stand-ins for browser versions that must be supported anyways.
No person's contribution is more valuable than supporting the human beings using older platforms, especially when many developers are so voracious to exclude them.
I've got the basics of a fix working that removes the dependency on the Babel Runtime: #250
I'm improving the API on the changes to be more like it was before, but it will be breaking, so we'll need to do a major release.
Resolved in #250