Reduce install size by 30%

[developit]

Hi @yannickcr! I'm working on reducing the disk usage of a typical ESlint setup, and found a couple cases where this plugin can be slimmed down with no functional impact:

• Object.entries is supported in Node 6+ and does not need to be polyfilled.
• Object.fromEntries is supported in Node 12+, and its usage here is minimal enough that an inline shim suffices.
• Array.prototype.includes is supported in Node 6+
• Object.values is supported in Node 7+

[developit]

Why would this plugin have any reason to support Node 4 when ESlint itself only supports Node 10+? That's a lot of baggage for no discernable gain.

[ljharb]

Because it also supports down to eslint 3, which supports node 4. The gain is backwards compatibility, and avoiding a semver-major bump.

[developit]

Have you evaluated the performance and disk usage tradeoff this is inherently making, or is this a purely philosophical stance?

[ljharb]

It's a dev tool; install speed impact is negligible and disk usage is irrelevant.

[developit]

I'm not sure that viewpoint is broadly shared. Developers have hundreds of projects on a machine, and this one is just under 8mb. Anecdotally, eslint-plugin-react accounts for more than 1GB of disk usage on my machine.

[ljharb]

I have almost 500 projects on my personal machine that are fully npm-installed, a handful of them using eslint-plugin-react, and the total size of the entire dir that holds them (including .git and node_modules and the actual code) is around 20GB, which is minuscule - anecdata is tricky :-/

If the goal is to take up less disk space, I'm happy to discuss ways to do that on those polyfill repos - that would have far greater impact than removing them from one eslint plugin.

[developit]

That seems like a reasonable plan - I don't have exact numbers on the % impact of the polyfill repos, but estimating based on packagephobia seems to indicate they're at least 50% of the disk usage of this plugin.

[TrySound]

Here's a number for one included polyfill. 3.39mb. Would be good at least to not have duplicated monstrous packages. Would be good to not pay for theoretical users of eslint 3 and node 4. https://packagephobia.com/[email protected] https://packagephobia.com/[email protected]

[chyzwar]

Maybe releasing library major version every 10 major version of node.js would be "stable enough". @ljharb how long do you plan to support node v4?

[onigoetz]

Are there stats somewhere on the actual users of ESLint 3, node.js 4 that need the latest eslint-plugin-react for React 18 ?

I understand that people could be using older versions of ESLint and node.js, but supporting runtimes that were released 7 years ago seems a bit overkill. Even more so that for people stuck on old versions of ESLint and node.js are also probably stuck on React 0.14

Releasing a new major version of eslint-plugin-react would still allow these people to use the previous major version for their use case.

[ljharb]

@onigoetz react 18 works just fine on ancient versions of node, so that assumption doesn't hold. Also, the instant we shipped a bugfix or a new feature, the folks stuck on the previous major would be left in the lurch. That's a high cost, compared to the virtually zero cost of "a few extra packages".

@chyzwar i maintain over 300 packages that still support node 0.4. So, "how long"? Probably forever.

[onigoetz]

True, maybe it would suck /if/ those people are actually using Node 4 and ESLint 3

On another hand, your package has 12'500'000 downloads a week, according to packagephobia, one install is 3.77MB (Unzipped, so let's say half that when transfered)

Which means (3.77/2)*12500000 = 23 562 500 MB = 23.5625 TB

In other words, this PR is proposing to shave off 7.8 TB of data transfer per week.

Here is an article written by chokidar's maintainer Paul Miller on how the newest version is massively smaller and the implications of that size : https://paulmillr.com/posts/chokidar-3-save-32tb-of-traffic/