search

gbv / cocoda-sdk

SDK for Cocoda and coli-conc services
https://gbv.github.io/cocoda-sdk/
MIT License
5 stars 1 forks source link

Reduce bundle size #28

Closed stefandesu closed 2 years ago

stefandesu commented 3 years ago

We should aim to reduce the bundle size. Some specific ideas:

Find cocoda-sdk's current bundle size here. (At the time of writing: 128.5 kB minified, 40.5 kB minified + gzipped.)

(Adding this to the 2.0.0 milestone because removing local mappings would be a breaking change.)

nichtich commented 3 years ago

We could split into individual packages for providers, e.g.

Should each be put in an individual git repository or bundle them here?

stefandesu commented 3 years ago

I thought maybe we could bundle it here, but release them as separate packages.

If used in a browser, I'm a bit unsure how we should deal with dependencies though. 🤔

stefandesu commented 2 years ago

I'm currently rewriting cocoda-sdk as an ES module which will allow us to use tree shaking to reduce the total bundle size when not everything is needed.

Require some packages to be included separately (for example, if a page uses both jskos-tools and cocoda-sdk, jskos-tools would basically be added twice because it is included in cocoda-sdk)

I would still do this for the browser bundle. The question is whether we should only exclude jskos-tools or other dependencies as well.

Reduce or eliminate Lodash usage

Still relevant in my opinion, but requires some work.

We could split into individual packages for providers

In theory, we could split the providers off and offer them as separate files for the browser bundle. However, since tree shaking is a thing and it's not an issue if you used Node, I'd say we don't need to do this.

stefandesu commented 2 years ago

I started replacing Lodash usage and noticed that it doesn't really reduce bundle size at all. Since the included Lodash methods are also tree-shaken, they add fairly little to the bundle.

For the browser bundle, we could still externalize some of the dependencies, but we can do that at a later point. I would assume most usage of cocoda-sdk will be either in Node or in an application that is developed via Node (and thus can use tree-shaking and doesn't duplicate dependencies).