Reduce the size of jsdom (and its dependencies)

I occasionally see the size of jsdom cited as a reason to avoid it and prefer lighter packages instead. While an extensive implementation of the web standards will never be tiny, I believe that the total installation size of jsdom (13 MB / 21,9 MB) could be cut in half by merely reducing bloat.

The sizes shown within parentheses are with and without disk compression, and accounting for the removal of subdependencies. These are the three most important changes we could make to reduce our installed size:

request/request-promise-core - (5,4 MB / 10,6 MB)

The big one. request includes many large dependencies which we have no need for. request-promise-core contributes a significant chunk on its own, since it depends on the whole lodash package (1,4 MB / 5,1 MB) and has yet to merge https://github.com/request/promise-core/pull/7.

Replacing these with either a lighter alternative dependency or a proper implementation of the Fetch Standard would be a large win.

acorn/acorn-globals/escodegen - (2,7 MB / 3 MB)

The acorn, acorn-globals and escodegen dependencies are only used when jsdom is browserified. While we should continue to support browserification, it is an uncommon way to use jsdom.

I believe it makes sense to make these dependencies optional the same way the canvas-related dependencies are.

jsdom/living/generated/ - (1,2 MB / 1,5 MB)

With all the dependencies above removed, the largest contributor to size is actually jsdom’s generated directory. While we obviously need this code in some form, there seems to be a lot of room for deduplication between these files.

[domenic]

https://mobile.twitter.com/slicknet/status/782274190451671040

[domenic]

Replacing these with either a lighter alternative dependency or a proper implementation of the Fetch Standard would be a large win.

For sure. Just a lot of work 😃.

I believe it makes sense to make these dependencies optional the same way the canvas-related dependencies are.

I would rather find a way to use the browser package.json field so that these don’t get loaded at runtime for Node consumers. I think I’m OK with Node consumers downloading extra packages, in order to give browser consumers a better out of the box experience, as long as it doesn’t impact startup time.

there seems to be a lot of room for deduplication between these files.

I’d be curious to see what concrete proposals there are, but in theory this seems doable. I’m not sure we’d want to e.g. minify the output though…