React-select v2 large bundle size

[thenano]

My webpack bundle size has increased by 52KiB when upgrading react-select from 1 -> 2. Is this correct or am I possibly doing something wrong? Could this be caused by the css-in-js change in the library? Following on from that, is there a way to extract that via webpack into it's own css file?

[smishr4]

Is anyone even concerned with the bundle size at all? That is why I recommend people coming to this package to not use it, it severely impacts the bundle size of your website.

if a single component like a multiselect causing your website bundle to grow 1.5x then dont try it, its a horrible decision, either look for a lightweight or try make one, with limited functionality that you need.

Do not star this repository, thx.

[justinryder]

Would love to have a way of importing this more modularly. There's a lot of great features in this, but the increase to bundle size is simply unacceptable. This package alone is almost 10 times the gzipped size of React itself!

I don't want CSS-in-JS. I don't want heaps of typescript definitions. I don't want a dependency on emotion. I just want an accessible multi select input that works on modern browsers.

[mattoni]

@justinryder agreed, haven't upgraded to v2 because of emotion dependency. That being said "heaps of typescript definitions" aren't actually built into your bundle and have 0 effect on the size.

[oskarleonard]

Yes, 30.2 gziped and minified is crazy. Maybe divide the components a bit, like import {LightweightDropdown} from 'react-select'; and let webpack tree shake out everything not related to LightweightDropdown . A lightweight alternative for now will be react-dropdown

react-dropdown
2.1kb -> https://bundlephobia.com/result?p=react-dropdown@1.6.4

react-select
30.2kb -> https://bundlephobia.com/result?p=react-select@2.3.0

[trillerpfeife]

Nice alternative but not so many options, though.
react-tag-autocomplete
https://bundlephobia.com/result?p=react-tag-autocomplete@5.10.0

[JedWatson]

That is why I recommend people coming to this package to not use it [...] Do not star this repository, thx.

Just to be clear, this sort of thing is not actually OK in open source projects. You're dealing with a lot of personal time and commitment from a team of people who have given you something for free which works pretty well for a lot of people and solves a lot of hard problems.

We're totally aware that size is a concern. Splitting packages up in a way that's friendly for the hundred different ways people will depend on and bundle them is hard. Trade-offs were made, and assuming it's for lack of care is arrogant.

I came here looking through issues at 2am - after my family has gone to sleep - to see if I can help someone with something. But fuck this, I'm gonna go to sleep instead.

---

What I actually came here to say: bundlephobia is misrepresenting the size for most use-cases. As long as you're using a modern bundler, you'll be using our modern esm build which is tree-shakeable. If you look at the breakdown of file size, 14% is react-transition-group which you'll only get if you include the Animation components. The Async and Creatable variants can also be shaken out if you're not using them.

Saying react-select is 10x the size of React is ridiculous. Once you include react-dom, where most of the code is that makes React work, even at the full 30k react-select is smaller.

Also, re: the emotion dependency, it's just over 6k gzipped. Compared to the size of the CSS we were distributing with v1, last I looked when we were working on v2, the combined size isn't actually that different.

Ironically, bundlephobia was under-reporting the weight of react-select for v1, because it doesn't count css - which was 10k before gzipping.

I have no doubt there are things we can do to optimise the size of this package, and there's stuff we're planning to make it even more tree-shakeable (exposing the core without styling is a good one) but a lot of the weight comes from features. Like diacritic support for filtering, accessibility, touch event handling, scroll event handling, etc.

[w01fgang]

That is why I recommend people coming to this package to not use it... Do not star this repository, thx.

@smishr4 If you don't understand the purpose of Open Source there is no place to you on the GitHub. I recommend you not to write comments until you create something useful.
Jed Watson created many packages that use thousands of people, which suggested to use by Facebook, also he created a great company and who are you? You don't have any rights to write stuff like this!
If you don't like something make it better! PR's are always welcome. If you don't know how to improve it, just shut up and go to school.

@JedWatson please don't listen to comments like this! Internet is accessible to any person of any level. Unfortunately, some of them have a low level of self-development, some of them are trolls and write only to make people angry. Next time if you will find a comment like this, be on the higher level so they can't touch you. "The cat does not care what mice say about it" And thank you very much for all the things that you do!

[smishr4]

Hey fellow developers I made that comment 6 months before, when I was new to developing open source projects and I forgot about this and had no memory of doing so. I accidentally clicked the notification tab and I stumbled upon this today.

I am sorry for making an insensitive comment, in fact I have realised myself how hard it is to make a reusable solution (even for the easiest problems) and maintain it to keep sync with new features of underlying framework used.

Back in the day I was strict opponent of using ui-plugins for development and thought it would be wiser to create a component tree of your own providing only functionality I need.

@w01fgang thanks for reminding I am unsuccessful in life and yes I have been disrespectful/rude/arrogant in the past but let me assure you I am trying to get better, Im brushing up my engineering skills, socialising with people and attending conferences. I've understood that things are doable, behaviour and attitude matters the most.

I was thinking of deleting the comment I made earlier, but I would rather keep it to remember my mistakes.

[JedWatson]

Thanks for that @smishr4. I think this sort of thing is important to call out, but we are all learning and I appreciate the apology. If this record can help others learn too, that seems like a good outcome ❤️

One of the greatest tools we have as developers and humans is empathy for others. Behaviour and attitude do matter most. It sounds like you're early in your journey but if my personal experience is that no matter what level you are, if you are supportive, helpful, and humble, your future self will be happy about it.

[smishr4]

@JedWatson I respect the noble work you are doing for the developer community and you have great skills to overcome the unknown (never faced by anyone before) kindof challenges. That was very stupid making such a crass comment even before taking a step or 2 on the journey that has been travelled by miles by the experts.
Now I realise that we need to lift up, encourage and help even the worst of the coders to make this community happier and better.

[w01fgang]

@smishr4 I'm glad that you understood and accepted the mistake, keep growing you are on the right way.

[JBethay]

I believe V3 should help alleviate some of this pressure (It did on my build anyway.) #3585

[thenano]

Excellent, upgrading to v3 has shaved off 20KiB in my build. @JedWatson I'm happy to close this.

[jondavidjohn]

I built a tool to help you analyze webpack bundles for size regressions, and report them directly to GitHub PRs. It's free for open source, so it might be worth checking out and helpful in this scenario.

https://packtracker.io

[JSONRice]

@JedWatson first and foremost thank you for your efforts. react-select is one of those rare open source projects that actually does one job and does it really well. I wanted to further understand how your code is bundled. I noticed you have a bunch of hash files under your dist and your esm is referencing some of that. It seems to me that the baseline select component really doesn't use up that much space (like you said without animations etc.). Have you seen:

https://www.npmjs.com/package/react-select-plus

React select plus has one dist and that has a JS file that really isn't that big:

I'm wondering what the baseline select component size is for react-select without any of the animations etc. attached. I ask because I'm building an app that needs to support users in countries with poor network infrastructure and heritage systems and want to make sure I'm using the leanest available modules. Thank you again for the countless hours you've spent developing react-select and for all your other contributions. It's much appreciated.

[w01fgang]

@jasonwr I used this nextjs to determine the real bundle size.
After adding react-select to the app, the bundle size grew for 93,86kB.

[rharriso]

Given previous comments here. I feel that I should say off the bat that this is a great library. None of the built in examples fit my use case, but it was flexible enough for me to get what I wanted to out of it.

Is there a recommended workaround for this issue? Material-UI, for example, recommends using up to three levels in the directory structure.

e.g.

import Button from '@material-ui/core/Button';
import Grid from '@material-ui/core/Grid';
import withStyles, { WithStyles } from '@material-ui/styles/withStyles';

Is something like that an option here?

[oliviertassinari]

Material-UI, for example, recommends using up to three levels in the directory structure.

@rharriso We have recently clarified the tradeoffs between the different import alternatives. You can start from here: https://material-ui.com/api/button/.

[rharriso]

@oliviertassinari Great! thanks for the update!

[JedWatson]

@oliviertassinari that's some great reading, thanks for linking it here! by the way - I've been consistently impressed with the work you and everyone else put into Material-UI, it's awesome ⭐️

Just circling back around to this: with @mitchellhamilton's help we've turned this into a monorepo using preconstruct which will give us a lot of new options about how we can better split and package the different modules going forward.

@jasonwr at the moment the whole setup is a bit compromised because there are so many people depending on this version, with different bundlers / usage / etc. Lessons have been learned 🙂 but it's hard to change without potentially breaking things.

I'm also planning to look into using hooks, which can help cut down implementation size (this will probably become v4 because of the massive internal changes) and with the next major release we'll take the opportunity to make it easier to opt in to different features when you need them, meaning more reliably small bundle sizes wherever possible 🤞

[JedWatson]

Also I think I'm going to close this (working through a lot of issues and PRs at the moment). Some great conversation here - thanks everyone. Still aware that this is larger than ideal, and will continue working to improve that!