Importing color picker imports all of babel and core-js - why?

My Meteor 1.8 / React project is using rc-color-picker on the front-end. I’m using dynamic code-splitting. On the route which imports the color picker tons of other modules are imported, including lots of babel-runtime, core-js and others. Is this normal, or something badly configured with this component or one of its dependencies, or something wrong with my setup?

Here’s 3 out of the 4 pages of modules which are fetched from the /__meteor__/dynamic-import end-point along with rc-color-picker on my production server. If I don’t import rc-color-picker none of these other modules are imported:

I guess this isn’t specifically a Meteor problem, but maybe I’ve got something wrong with my Meteor build process. Any ideas?

I’ve raised a bug here, but no response there yet…

I’m not that familiar with npm modules and their dependencies, devDependencies or peerDependencies so I don’t really know where to start tracking down which module is causing this. Any help is greatly appreciated.

You can see the dependency tree of an npm package here
http://npm.anvaka.com/#/view/2d/rc-color-picker

1 Like

Looks like it’s just a function of it’s dependencies.
The good thing about Meteor’s dependency management and bundle splitting is that it caches individual modules instead of bundles, so if you dynamically import a component that shares a dependency with an old bundle, it will skip sending the shared dep and just load it from the browser cache

What is the size of the dynamic import payload in the network tab?
Given the above it shouldn’t actually re-send babel and core-js, but it always pays to check!

Thanks @rjdavid, that’s a useful tool!

@coagmano, yes, Meteor’s awesome IndexedDB cache of dynamic imports means this payload only happens for first-time visits to that route. The above screenshot was taken from an Incognito tab to demonstate the sheer number of dependencies of the rc-color-picker module.

The size of that import is 96kB zipped (374kB unzipped). If I remove rc-color-picker then my own components and other dependencies are only 1.3kB (3kB unzipped).

None of the modules shown in the above screenshot are required by any other routes - only this route which imports the rc-color-picker component. My question comes back to: why is a relatively simple component importing lots of babel-runtime and core-js in production when nothing else in my React UI seems to need them? Is it a poorly written module, or something wrong with my setup?

Thanks.

Yeah it just seems to be an unfortunately large dependency chain:
rc-color-picker -> rc-utils -> babel-runtime@6 -> core-js
(and other paths to core-js)

It still seems to be a topic of active debate in the js community as to whether to transpile modules for ES5 environments (and bring along run-time polyfills like this) or to publish modern javascript and require the use of bundlers and build tools (like Meteor) to support legacy targets

1 Like

Thanks @coagmano, I guess I’ll look for a React colour picker component with fewer/better dependencies.

Thing is, I thought I’d already done that. rc-color-picker seems to have fewer dependencies than some of the alternatives. It’s not until you use a tool like the one posted by @rjdavid that you see all the sub-dependencies. It would be nice if https://www.npmjs.com gave an idea of the full dependency payload.

Happy Christmas everyone, thanks for your help!

2 Likes

I found this tool which tells you the bundle size of a module and its dependencies: https://bundlephobia.com