Redux-toolkit: Size of bundle

Created on 25 Nov 2019  路  5Comments  路  Source: reduxjs/redux-toolkit

Hello there! Could you please reduce size of the bundle? Seems like there is a lot of unnecessary things. https://bundlephobia.com/result?p=@reduxjs/toolkit@1.0.4

Most helpful comment

That wouldn't really work out on a large scale.

Assume jest. If every depenency of jest were a peerDependency, and if every one of those had all their dependencies as peerDependencies, you would have to manually add ~1500 dependencies to your project. If you want control over those, that's what a lockfile is for, not your package.json.

Also, these aren't peer dependencies. We want these to be at least installed when RTK is installed.
The whole point of re-exporting redux and reselect is that people can use them without having to install two additional packages. The idea of RTK is to make things easier for the user, not more difficult.
If these dependencies aren't being used in the end, it's the bundler's job to not include them (see tree-shaking).

All 5 comments

Could you please elaborate what exactly in there is unnecessary?

Here's my take on that statistic, but I'm keen to know if you've got another opinion on that :)

The main size increase here is immer, which is fundamental to createReducer and createSlice. We're working on tree-shaking (#78), but if you're using RSK, chances are that you use one of these two methods.
Also, the size of immer is alleviated pretty quickly, because you're going to write much shorter reducers, so in the end that pays for itself.

Next thing is redux - and the idea here is that you don't have to specify redux as a project dependency, but that RSK is including that by itself.

Same argument goes for reselect. And that's AFAIK already tree-shakable if you're not using it.

All the other dependencies make up less than 1kb - un-gzipped. Gzipped that will be much lower.

I think that better when library includes only self code and all external deps goes as peerDependencies.

That wouldn't really work out on a large scale.

Assume jest. If every depenency of jest were a peerDependency, and if every one of those had all their dependencies as peerDependencies, you would have to manually add ~1500 dependencies to your project. If you want control over those, that's what a lockfile is for, not your package.json.

Also, these aren't peer dependencies. We want these to be at least installed when RTK is installed.
The whole point of re-exporting redux and reselect is that people can use them without having to install two additional packages. The idea of RTK is to make things easier for the user, not more difficult.
If these dependencies aren't being used in the end, it's the bundler's job to not include them (see tree-shaking).

Jest is dev tool. Users do not upload jest, when coming on website.
I respect your point, but I am still little bit confused by webpack and devtools extension in bundle.
I know, they are small, but anyway looks strange)

I'm not sure what the "webpack" portion of that is, tbh. I don't see any mentions of Webpack in the actual /dist output.

The redux-devtools-extension part here isn't the actual browser extension - it's https://www.npmjs.com/package/redux-devtools-extension , which encapsulate the process of enabling your store to talk to the extension.

As @phryneas said, we're working on improving tree-shaking, but the point of RTK is definitely to have all these other dependencies pulled in automatically without having to specify them, and realistically we expect that folks _are_ going to be using all of these in a real app.

I'll go ahead and close this, as we've got the other issues related to tree-shaking already.

Was this page helpful?
0 / 5 - 0 ratings