2.0.0 bundle size

[Hurtak]

Hi,

It seems that the bundle size difference of 2.0.0 vs 1.1.4 is 3x in minified code size and 2x in min+gzip which seems like a lot.

Stats reported from import cost plugin in VS Code

• version 1.1.4, size 23KB, 8KB minified
• version 2.0.0, size 63KB, 15KB minified

Stats from my CRA application after updating to 2.0.0

• bundle size 84.21 KB, diff from 1.1.4 bundle size +7.63 KB (only change between the builds was update of react-hotkeys)
• this corresponds to the stats reported by import cost plugin

I wonder if the bundle size could be cut down closer 1.x.x sizes.

[greena13]

Hi @Hurtak,

Thanks for taking the time to raise this.

At the outset, I'd like to say monitoring bundle size is not something I am particularly strong in. I have looked into the best way of tracking it a couple of times and have never really come away with a clear answer.

But if you'll permit me, I'd like to run through a few reasons why version 2.0.0 is indeed significantly larger than v1.1.4.

With the removal of mousetrap, react-hotkeys now handles all key map detection and matching. So I have had to effectively replace mousetrap's entire functionality. This was done to better integrate with React, and to lean on its key standardisation and synthetic event system. I wonder if the ways you're using to measure the bundle size subtract the size of mousetrap.

v2.0.0 also provides a significant number of optimisations, bugfixes and additional functionality - this unfortunately does require additional code. The release notes give a good overview of those.

As bundle size has been something I've tried to be mindful of, a number of steps have been taken to attempt to reduce it:

• All comments and (virtually all) logging are stripped from the production build.
• Uglification and minification are used to reduce the production build
• The "files" attribute is used in package.json to ensure only essential files are included in the published bundle.
• The "modules" package.json attribute points to a ES6 module release that should allow tree shaking, and only including the files that are actually required by the consuming project. (This is something I don't have a confident understanding of, so it may not be functioning as intended).
• The production build is built with rollup.js, which as I understand it, is currently the best tool for producing the smallest bundles, with ES6 module support.
• Where possible, I've tried to normalize (de-dupe) all code to maximise the re-use of each routine and reduce the size of the source code

There are a few things I can try, to get the bundle size down:

• Upgrade all development dependencies and make sure react-hotkeys is being built with the most up-to-date ES5 transpilation algorithms.
• Check that production optimisation measures are indeed working as expected
• Look into measures for producing reliable and consistent reporting on bundle size

There is also (hopefully) good news that the bundle will get slightly smaller in subsequent versions:

• The next major release will be a refactor of v2.0, with a significantly more modularised architecture that should help to further reduce any code duplication. It will provide the exact same (supported) API as v2.0.
• The next major release will also likely remove deprecated features which have been left in v2.0. for the time being, to aide people in migrating to the new API.

Please let me know if you have any other ideas or thoughts on how the bundle size may be reduced further.

[Hurtak]

Hi,

thanks for the detailed answer and for the hard work on this great library!

I think you are doing everything right when it comes to optimization, the only thing that comes to mind would be some lightweight build that would cover only some basic functionality (not sure if that would actually help) but I think this library is not that big to have this additional complexity justified. We will see what happens at 3.0 that will remove the deprecated features.

Cheers

[greena13]

Yes, a possibility I forgot to mention is that parts of the library may be able to be abstracted into optional plugin packages. At the moment, react-hotkeys isn't set up for plugins, and the things that come to mind for abstraction are the legacy backwards compatible components. But there may be something that makes itself known as I continue to think about it.

Similarly, I don't think there is currently much to jettison for a stripped down version. I also don't particularly like the idea of maintain two libraries, when I can barely keep up with one.

But I'm open to suggestions on optional features that may be spun off, and are worth the hassle of doing so when it comes to bundle size.

Thanks for putting this back on my radar. I shall endeavour to find a more consistent and systematic way of tracking bundle size in the future so it remains at the forefront of my mind.

[steveadams]

Let me know if you'd like a hand with this. My team has been working hard on bundle optimizations and we'd actually like to use this library if it weren't for the bundle size. Every byte makes a difference for us. I'd be happy to help out if it could lead to use implementing react-hotkeys in our product.