Bundle Analyzer

[00:00:00]
>> Now that we've talked about making that work, making it right in terms of testing, let's take a moment and let's talk about a couple of techniques use for really analyzing. Are we building this correctly? How do we make it faster? How do we make it better? And then ultimately, how do we put it into production.

[00:00:20]
And so one of the things that I wanna show real quick example is the footprint of your application and we're gonna do this with a bundle analyzer. And so within this what I want to do is in I Command line here is I'm going to install a package.

[00:00:47]
I already had this installed, but I'm going to do it again. Just because we're going to assume that we're doing this from scratch. So bundle analyzer and we're going to save dev. So this is the webpack bundle analyzer that allows us to look at our webpack bundles and see what It actually consists of.

[00:01:10]
So I'm going to run this. And it's going to install this and so while this is installing this. What I'm going to do is I'm going to hop back into my code, and I'm going to open up my package.json file. And then from here, I'm going to have these two commands that I'm going to just delete.

[00:01:34]
I'm going to just re type them so I can talk about them as I am or offer commentary as I'm typing them. So, I'm gonna create a new command and it's called build stats. And what this is gonna do is we're gonna use ng build and we're going to use this flag stats json.

[00:01:57]
And so what this does is that it does a build and it exports this json file that has stats about the build. And then from here I'm going to add one more command, this is called analyze. And within this I'm going to go webpack-bundle-analyzer. And then we're going to point this to the dashboard kind of folder.

[00:02:26]
So we're when we build this it generates a build within the disk folder so apps dashboard/stats. And we're looking for the stats.json on file and so when we do the build, it's going to build it and it's going to create the stats.json file. So I'm gonna save this and hopefully the package installed correctly.

[00:02:53]
I would expect it would. And so from here, I'm going to go npm run, build stats. And so we're gonna let this run and it's gonna do a build, but it's gonna generate the stats.json file. So it's gonna run the build. And we'll give this just a second.

[00:03:15]
And we'll hop over into the code one more time. And we'll look in the disk folder and within the disc folder apps dashboard. And then you can see right here, we have the stats.json was just has a bunch of information about the project. So from here, let me go back into my command line.

[00:03:40]
And I'm going to run npm run, analyse And what this has done and this went to my other screen is it generated this particular file and loaded this up so this is a really good way for us to see the chunks of our application. So we'll notice here that our vendor js, it's pretty big, it's 5.45 megabytes, and our styles are okay.

[00:04:18]
Everything is fine, but really this vendor file, this bundle is really, really big, and so we'll notice here that maybe part of this is angular, as you can expect. Now the one thing that I would so immediately is if you look over at this section here, it is your material components?

[00:04:46]
And I would immediately ask myself, what components and am not using, so I'm not using the slider, that's 50 k gone. I don't think I'm using the table. And so I would go through and I would start to remove the things that I am not using. So this is a really good way to very quickly see what is taking up all of the space within the bundle.

[00:05:14]
And so very very simple technique. You just run you add the webpack bundle analyzer then within that, you are able to essentially run a build with the bill or the json flag. So let me just pull this up. One more More time. So we start with stats json, and then from there, you're able to analyze it by running the web pack bundle analyzer and pointing it to that stats.json file.

[00:05:47]
Now that we've seen how to analyze the bundle size, and we saw that it was very, very large, I want to illustrate another technique for analyzing the kind of the state of your application. And this is using the dependency graph command. So, I'm gonna hop back into my code or my command line here, and I'm going to run nx dep graph and I'm going to set the file output to, or rather the file to be output.html.

[00:06:24]
So let's go ahead and run this. And you'll see here that it generated some files here. So If we go into the output.html, but some additional things within the root of the application, so I'm gonna close everything. And then if you'll notice in the sidebar, I now have this static folder.

[00:06:49]
But in the root of this, I now have this output .html. And so what I can do here is I can just open this up in a browser. I'll just drag this over here. And what this allows us to do is select our projects. And we have three of them.

[00:07:15]
And then we can select our lips. So right now we have three projects, and they're totally unrelated. But let's take like ui toolbar. Well now we know that dashboard and client are utilizing ui toolbar. Testing well we've only written end test or unit testing for dashboard so that's why you're seeing that.

[00:07:39]
Material, so this is interesting that dashboard client and ui toolbar has a dependency on material. And so I'm gonna go ahead and just select all of these. And what you can start to see very quickly is that or visualize the dependency graph that exists within your monorepo. And so this is a really good way when you start to analyze dependencies and what your application could be dependent on you can very, very quickly see that maybe I do not need this dependency.

[00:08:21]
Or maybe this dependency existed that I wasn't aware of. And so this is a very nice way to very quickly analyze the dependency graph of your entire monorepo and get a very good idea of how everything is connected. So not only is this good for, I would say, analyzing performance dependencies and looking for ways to possibly optimize it.

[00:08:51]
But this is really good documentation. And so what I would do here is I would just save a screenshot or export this in some way and put this into even the remi. Or some kind of a knowledge-based to analyze the dependencies within this application or within the repo for purely documentation and onboarding into that project.

[00:09:24]
So that was, again, very straightforward, very simple way to surface a ton of great information about your application very, very quickly.