Provide unminified ES5 code as a target

[adrm]

Expected Behavior

The bundle size should be as small as possible.

Current Behavior

Although britecharts works fine with webpack and it only bundles the required charts as expected, right now every chart imported is weighting more than 100KiB parsed and around 45KiB gzipped, which I think it's too much.

Possible Solution

I don't know if I am doing something wrong, but I can see that webpack imports from dist/umd so maybe the imports are already bundling multiple dependencies that could be shared across charts.

[Golodhros]

Hi @adrm , thanks for creating an issue!

Totally agree, the bundle size should be as small as possible. Right now, when you load one of our charts, its bundle contains all the D3 modules that chart needs (you will only d3-selection to make it work).

Other users have voiced their concerns and it seems that we will be working on a new build target that would be unminified ES5 code in UMD or CommonJS format, so you can use your Webpack to create a bundle and avoid repeated dependencies.

Would that work for your use case?

[adrm]

Yes! That would be perfect. That would allow webpack to optimize the bundle and avoid the duplicated dependencies. The bloat was a big concern when choosing the library, so I hope you can fix this soon.

Thanks a lot for your work, it's working perfectly.

[miglesiasEB]

Looking into this it seems there isn't a way of doing it through webpack: webpack/webpack#2933

However, there seems to be a babel based solution commented in this response: https://stackoverflow.com/questions/41289200/output-an-es-module-using-webpack?answertab=votes#tab-top that could be useful.

I don't have a lot of background on babel, so any kind of help would be appreciated.

[wyaeld]

So the @Golodhros solution works fine for britecharts-react itself, if you import modules using the lib/esm path it gets tree-shaken with webpack and results in minimal size.

Is there preventing this same technique from being applied to britecharts core? It appears to be a hefty 380kb zipped, which I expect is a lot of the d3, but we use D3 elsewhere too and import it in ways that webpack can tree-shake

Update: something must be misconfigured, because I can see that the brightcharts-react components already import from the minified umd of brightcharts, but just importing 2 charts isn't preventing the entirety of brightcharts coming in, and those individual .min files are rather large

[Golodhros]

Hi @wyaeld, thanks for your comment!

So, we definitely want to do this in Britecharts too. I will be super helpful. The first roadblock we have is that we need to transform our current AMD modules into ES modules. Once we do that, we should be able to apply the same setup we have in Britecharts-React and allow tree-shaking.

Regarding the inclusion of D3 within Britecharts, I had that question in my head for a long time. Should we pack the necessary pieces of D3 with our charts or should we allow users to use their own D3.js? At first, we favored the 'package' side of it, making it something self-contained (the whole library and the individual charts have the D3 parts they need, but they require the user to have d3-selection), but now we see that maybe that's not the best approach.

We could also proxy d3-selection to have it all there (it's already in the chart), or we could make d3 a dependency for Britecharts and hope that the users have the build tool configured to only use the needed modules.

What do you think?

[exequiel09]

What's the status of this issue?

[Golodhros]

Not much movement I am afraid.

As commented before, we need to first move Britecharts to use ES6 modules, then we could easily add the ES modules as a target as we do in Britecharts-React.

I would need help with the first task.

[Golodhros]

Provide unminified ES5 code as a target #429

[adrm]

Maybe this issue can be closed in favor of #714 ? I understand that the problems that motivated this issue would be solved by distributing ES modules.

[Golodhros]

Well, they are closely related but not exactly the same. We can keep both.

[Golodhros]

Done as part of V3 development.

Try this installing britecharts@next