View Package Sizes in a React App with Webpack Analyzer

Instructor: [0:00] One of my favorite tools to use when it comes to checking the overall build size of your React app is the Webpack Bundle Analyzer. As you can see here, I'm installing it as a dev dependency to my React app. Go ahead and do that whether you're using npm or yarn just like this.

[0:20] Once that's done installing, head over to whatever file you use to configure your Webpack. I ejected from Create React app, so it's just this webpack.config file for me. I'm going to require this Webpack Bundle Analyzer. This is simply a plug-in that we can run inside of our Webpack.

[0:41] We'll just new up that bundle analyzer plug-in option which we just created up at the top. With that in there and if I do a yarn start against my application again, you'll notice that not only will it rerun my localhost:3000, my app that I have set up here.

[0:59] It's also going to create a new tab here that showcases all of the node modules that I have and all of the app itself broken up by science. You'll notice that inside of this static zero chunk here, the node modules is everything inside of this section.

[1:18] On the right here, we have the source components and all those other little things that make up this app. You can see that I have some pretty large chunks of code in here. One thing I want to notice on is this Lodash. You'll notice that it's big and takes up a lot of space.

[1:36] This is probably unnecessary because I'm only using it in one spot inside of my application. That's going to be inside of this useMouse hook. All I'm using here is Lodash to do one function, to do a debounce when I'm looking up my mouse is positioned.

[1:53] Only using that one function from Lodash is taking up a large chunk of code inside of my app. This visualizer here is helping me realize what npm packages that I'm working with are taking up the most space.

[2:09] This makes me think about how I could rework this to make it smaller. One thing I can do is use a tree shaking mentality where I'm only importing the debounce function itself versus the entire Lodash library. With that in there, I'm not losing any functionality at all.

[2:27] If I rerun this and see what that looks like, we're able to see that I was able to get rid of one of those Lodash chunks versus two of them. I've already successfully made my total build even smaller, but then it makes me think, can I not just create my own debounce functionality?

[2:49] Again, I'm only using this one debounce function inside of my code from Lodash. Is there a way that I can create my own universal debounce function when I'm really not doing too much of a crazy thing to it.

[3:04] I am just simply saying set the mouse position after this amount of time. For kicks and giggles, I did actually go ahead and put that code together. I have just a debounce function. It has some time out in here that, depending on what time we give it here of a delay, it'll run for us.

[3:22] You also need to use a useCallback to make it work within a React context. Now that I have this debounce function in here, I don't need Lodash anymore. This is the only place I was using it in my app and I've already created this own debounce function here.

[3:38] This is one less thing that I can have inside of my app. Now I can go over to my package JSON, delete the Lodash dependencies. Now I can see that I'm using even less code when I run my Webpack Analyzer again.

[3:54] By starting this, we'll check out our browser and let it open up a new tab of our Webpack Analyzer. First thing we'll notice that that debounce function does work. You can notice in the console that it's not constantly popping out console logs. It's just being debounced.

[4:11] Back inside of our Webpack Analyzer page, you'll notice that Lodash is still here, but it's because it's a dependency of why did you render. It's also to the right of it in a smaller tile. It's because Lodash is being used by other tools and dependencies within dependencies.

[4:27] It still is inside of our app, but we've limited it to be the lowest amount as possible inside the app by completely removing it from our own code base inside of my React app.

[4:40] What's nice about this is you can actually zoom in to each section and you can see the size of all of these other packages. It's got full interactivity here. We can zoom into our components and see which components are the largest.

[4:56] Maybe we can go back through and we work them a little bit. As you can see, this does help us get an idea of what takes up the most space inside of our bundles. There are also other ways to use this.

[5:08] You can use it as a CLI and just run it versus having it be inside of your Webpack config file running as a plug-in. Then there's also a lot of customization to this plug-in. You can customize it to show additional information to each one of the packages.