To set up a professional Next.js AppRouter application, you're going to want a couple of checks that are made both locally before you submit your PR to your repo, as well as in the repo. So we're going to walk through an example of that in this video. We're going to use a bundle size checker to actually check the bundle size of the application. That is a fantastic check that you are going to want to have on your Next.js application. An out-of-control bundle can be a serious performance problem.
So having the bundle size checked on every single PR is super valuable. And you'll learn that in this video, how to go and check your bundle size. We'll go and look at GitHub Actions, which is one way to run those checks on your PRs, if you use GitHub. And then we'll also look at Husky, which is a way to make sure that those checks are run locally before you even PR. So you're gonna learn three cool things in this video.
Let's start off by building our example application. So I'm gonna call this Next.js App Writer Application bundle size checker. It really doesn't matter the settings that we're gonna use. We're not actually gonna run the application. All we're gonna do is just check to see that the sample application that makes out of the box fits within our bundle size requirements, and then we'll go and add some outrageous stuff to it to max out the bundle, and we will then see it fail locally and also on GitHub.
So I'm just going to take all my defaults, and then I'll bring it up in VS Code. Now that we have our example application, we're going to create a GitHub repo and we're going to post our application to that GitHub repo. So over here on GitHub, I'm going to create a new repository. I'm going to call this bundle size checker, and I'm just going to make it private. I'm going to take the specification for remote, copy that, go over to my Visual Studio Code and bring up the terminal.
Now, next day, it's automatically initialized to GitHub repository for us. So I'm just going to go and add that remote to the pre-existing Git repository. Let's see if there's anything to check in. There isn't, we're good. So I'm going to then push that to master.
So I'll copy and paste the git push origin main, drop that into my terminal, and there we go. Now we're up on GitHub. Let's go take a look. Next thing to do is to go and add the bundle watcher. And this is the kind of thing that you're going to want to do early on in your application to create a baseline.
So what we're going to do is we're going to add something called bundle watch. Now there are a bunch of different options in this space. I'm just picking bundle watch as one of the ones that is off the shelf. If you want to use that, that's fine. If you want to use one of the others, feel free to go and research that on your own.
So the first thing I want to do is add this BundleWatch library to our application. Back in our terminal, I'm going to add that dev dependency of BundleWatch. Now that that's installed, we have to configure it. And there are multiple different ways to configure it. You can create a config file in the root directory, or if you want to keep your root directory clean, like I tend to, you can go and add the configuration to your package.json.
So let's go check that out. So over in our package.json, I'll just add a key for BundleWatch. In there, I'll give it the location of the files that it's going to check. We're going to use the .next directory. That's where our build goes.
We're going to check all the JavaScript files inside of the .NEXT directory and then we're going to set a threshold. How big do we want our chunks and our bundles to be? We'll set that right now at 100K. You can set that wherever you think is appropriate. Down the CI section, you need to find what the main branch is.
Ours is main, the default is actually master, and then whatever branches you want to track. So in this case, we're just going to track main. But if you have a development branch and a staging branch, you might want to add those. Let's save. And now let's give it a try.
So to give it a try we'll go over in our terminal and then do pmpm bundle watch. Okay now that failed because it can't actually find those files. So the first thing we really need to do is build our application. So let's build our application. As we look up here, we can see that the first page load is 89K, so that's under the 100K limit.
So we probably will be fine. So let's actually run our bundle watch. All right, we get a passing report here. It actually goes through and looks at all the JavaScript files and we can see the size and then the target size and everything currently is under 100K, which means that we passed. So now that we know that we're passing, we want to go and actually run this on GitHub.
So what we're going to do is we're going to create a GitHub action that's going to run our Bundle Watch on GitHub when we submit a PR. So first thing you need to do is add a GitHub directory. Now, actions in this case are called workflows. We're going to create a workflows directory and I'm going to create a bundle size workflow inside that directory. And it's going to be a YAML file.
So YML is the extension. You can name this file really whatever you want. I recommend naming it what you want to do, which in this case is checking the bundle size. So I'm going to bring in the YAML for this configuration file. It's in your instructions, and I'll walk through it step-by-step.
First, we're going to name it bundle size check. We're going to say that it's triggered on a pull request or any push to main. We're going to set the working directory to slash. If you have a monorepo, obviously, that's going to be within one of the app directories. Then we get the important parts around the environment variables.
We're going to set the repo owner as well as the repo name. We're going to grab the commit SHA from GitHub. We're going to say that our main branch is main. Then we're going to give it the BundleWatch GitHub token. So BundleWatch actually has a small service attached to it.
When you set up BundleWatch, you'll get a BundleWatch GitHub token. You're gonna wanna put that in the secrets. So I'm gonna go do that right now. I'm gonna grab this BundleWatch GitHub token. I'm gonna go back to our application over in GitHub.
Go to the settings, and then under secrets and variables, under actions, I'm gonna create a new repository secret. I'm going to put in my secret you don't get to see that. Now it's all set Let's go back to our YAML file and keep on looking at how that's going to work. Next we give it some permissions. We need to read from the contents of the repo as well as the actions, but we also want to write to the pull request.
So when the pull request fails, we'll write information to the pull request to say that it's failed. Let's go ahead now take a look at the job stuff. This is where we actually get the step-by-step of how we're gonna run this thing. So we're gonna start by saying that we're on Ubuntu latest, which we're going to use as the Docker image, and then we are gonna check out our code. We're gonna install nodes so we actually have something to run.
Then we're gonna set up PMPM. By default I think only MPM is in there. If you want to use PMPM or Yarn, you need to go and add those. Then we're gonna use PMPM install just like we would locally. Next up we're gonna restore the next build cache.
This comes in really handy if you're creating a lot of PRs. You can go and actually cache off part of the build. That's going to make for a faster build on the CI system. And finally, then we're going to build our next app. And then we're going to run our bundle watch command, just like we did locally.
All right, let's hit save and let's check it in. So I'm going to add these revisions, then I'm going to commit it, and then I'm going to push it to GitHub. Let's go have a look. So I look over here at actions, we should actually see our first action kicked off. Let's go and click on that, go and analyze, and now we can actually see it starting to run.
All right, We've successfully done our PMPM install. We didn't find any cache because we've never built here before. So we're gonna actually build the cache in this step, but now we're actually building the app. All right, it looks like we're done. Let's go check it out what happened here.
We went and did our build. It shows exactly the same numbers as it did locally. Then I ran our bundle watch, which actually did pass, and it gave us this result breakdown URL. We can click on that. We get this really nice report about all of the different bundle files and where they're currently sitting based against our maximum size threshold.
That's really cool. All right, so let's go and make this fail. So go back into our code. Now I hate to pick up material UI, I love that library, but that is what I'm gonna use to make the bundle size much larger by importing it the wrong way. So let's go and bring in material.
So material brings in material as well as emotion and emotion styled. And then over in our homepage, we're gonna bring in button, but we're gonna do it the seriously wrong way. Don't do it this way. So on our import, we are going to import the entirety of material as the material key. And from that, I'm just gonna pull out the material UI button, and I'm gonna use material.button to invoke that.
So what's actually happening is, normally, Next.js does a fantastic job of tree pruning, meaning that it goes and it finds all the code that you don't use in that application during its optimization build. This is actually circumventing that. So it's making sure that we're absolutely pushing in everything in material, which is definitely gonna bust out our 100 KB limit. So let's try this out. So I'm gonna do this locally first, make our terminal a bit bigger.
I'll do the build. We get some nasty little errors and then we scroll up We can see that the first load JS size is 254 kilobytes, so this is definitely going to go over. So let's run our local bundle watch. Now we can see the bundle watch failed. Let's go check out why.
So if we scroll up here, we'll see that we failed on some chunks. So we failed on this 403 chunk, and then we also failed on the overall page.js file. So that's basically the compiled JS file is bringing in all the material. That's 176K where we need to be less than 100K. But let's check it in anyway.
Now, the way that we're gonna do that is we're gonna create a PR. So I'm gonna create a PR by creating a new branch. I'll call it add material the wrong way. Again, this is the wrong way. Don't do it this way.
I'm going to add all my files to that and I'm going to commit it. I'll say don't do it this way. Now that that's all committed, I'm going to push that up to GitHub. All right. Now it's telling me I need to create a pull request for that.
So I'm going to option click there. And I'll just simply create the pull request. And that's now going to trigger our action. So let's go take a look at our action. We can see that Our don't do it this way PR has triggered the action and we'll go in here, check out the analyze.
Now we're getting a little bit of a build performance enhancement because we're using that Next.js build cache. We're getting the same error as NCI that we were locally, so that's a good sign. We're getting the same bulky page sizes, 254 KB, and we have failed our max size check, and in fact, we can scroll backwards and see that we now have a result breakdown. Let's go look at that. We can see that our normal page size is 160 KB less than where it is currently.
Really nice. And we go back and we take a look at the PR. We can actually see that that's failing. We can actually see that we've got the details there. This is absolutely fantastic.
So this means that no one will be able to PR into the main branch if they exceed the bundle size limits that we've set. And honestly, that is fantastic. You really want to set that up very early in your application to give yourself a nice healthy baseline for where your bundle size should be because bundle size has an immense impact on performance. Now it's kind of a drag that I had to burn CI to figure out that we had this issue. It would be great to actually run this locally.
So how do we do that? Well, we can install Husky. Let's go check it out back in our Visual Studio Code. I'm going to run mpx husky init. That's going to initialize Husky.
Now I'm just going to try and commit this. We can see that Husky is actually run. So it's missing a script for test. So if I go over here to our Husky pre-commit configuration, we can see that it's trying to do an NPM test. So let's go and add some tests.
We'll go over to our package.json, and we can see that in the script section, that Husky init is automatically added a prepare that calls Husky. So let's go and add our tests. In this case, all we're going to do is run that bundle size, which in turn is going to run BundleWatch. Now, if you had multiple tests, like you had an EDE test and a unit test, you'd want to add those as well, and then run those in whatever sequence you wanted. Let's hit save.
Now we'll try doing our commit again to see if this works. And now we were actually running our bundle watch and it failed. But what if I haven't built? So let's go and add in a build here and that will run build before running test. Try that again.
Alright it's doing its build and it fails. That just makes sure that you are actually checking the most recent build. You don't want somebody actually having an old build that didn't have in this case material in it and then saying well it works and then checking that in. So which would fail obviously in the CI but still you want to make sure that it's up to date. So that's why you might go and change your pre-commit hook or any of the other commit hooks.
Husky is a fantastic way to make sure that your code quality is where you want it to be before you make the PR. Well, there you go. We've taken a look at how to do bundle size checking, which is incredibly valuable, how to run that on GitHub, and also how to run that locally to ensure that your PRs are all good before you check them in.
Keeping bundle size under control is important for maintaining optimal performance. To help with this, we'll use GitHub Actions to automate bundle size checks on pull requests and pushes to the main branch. Additionally, we'll use Husky to run these same checks locally before committing code.
Setting Up a Next.js Project
We'll start by creating a basic Next.js application:
In this case, the specific name and settings aren't important as we won't actually be running the application itself. Our primary goal is to ensure that the initial application generated by Next.js meets our bundle size requirements and then observe how adding bulky dependencies can cause those checks to fail.
GitHub Repo Setup
Next, we'll create a GitHub repository to host our project and enable the integration of GitHub Actions for automated checks.
Follow the steps to create a private repo, then push your existing code to the main branch:
Integrate BundleWatch
We'll use a tool called BundleWatch to analyze and monitor our bundle size.
Install BundleWatch as a development dependency:
pnpm add bundlewatch -D
There are multiple ways to configure BundleWatch, but we'll add a section to our package.json file:
This configuration specifies the files to analyze, the acceptable size threshold, and the branches to track.
The path points to the .next directory, which is where the built files go. The maxSize sets the limit for the bundle size. The ci options rell the tool to only run on the main branch for this project (you will want to adjust this based on your branching strategy).
Once the configuration has been added, build the application:
pnpm build
After running the build, we can see that the first load is 89.5kB for the main page.
Running BundleWatch will tell us for sure:
pnpm bundlewatch
The output will display a report of the bundle sizes for various JavaScript files within the .next directory, comparing them against the specified threshold:
Now that we know BundleWatch works, let's set it up with GitHub Actions.
Implementing GitHub Actions Workflow
The first step is to create a .github/workflows directory in the root of your project. Then within this directory, create a YAML file named bundle-size.yml to define the workflow.
The on key says that the workflow should run on any pull request, push to the main branch, or manually triggered workflow dispatch.
The defaults section sets the working directory for the workflow. This is ./ in our case, but would be one of the app directories in a monorepo.
The env section of the configuration defines environment variables used in the workflow that should be edited accordingly.
The jobs section contains the steps to be executed. The analyze job checks out the code, installs Node.js, sets up the cache, builds the Next.js app, and runs BundleWatch to analyze the bundle size. These commands are similar to what we ran locally.
Setting Up Environment Variables
Head to the "Settings" section of your GitHub repo. Under the "Secrets and Variables" section is an option for Actions.
Here you can add a new secret named BUNDLEWATCH_GITHUB_TOKEN and paste in the token you obtained from the BundleWatch website.
Running the Action
Once you've saved the configuration, commit changes to the main branch. This will trigger the GitHub Actions workflow to run.
From the repo page, click the Actions tab. You should see the workflow running:
Once the workflow completes, you'll see the results of the bundle size check. If the bundle size exceeds the specified limit, the check will fail, preventing the PR from being merged.
Simulating a Bundle Size Issue
Let's introduce a deliberate bundle size problem to observe how our checks react. We'll improperly import the Material-UI library, which will cause a significant increase in bundle size.
Note that Next.js normally does a good job at tree pruning to only include the necessary parts of a library. However, by importing the entire library, we're bypassing this optimization.
Build the application again:
pnpm build
In the output you'll notice some errors, along with a new bundle size of 254kB:
Now when we run BundleWatch again, we'll see that the check fails due to the bundle size exceeding the 100kB limit:
pnpm bundlewatch
Creating a New Branch
Create a new Git branch and commit the changes, then push the branch to your GitHub repository.
git checkout -b add-material-the-wrong-waygit add -Agit commit -m "Add Material UI the wrong way"
With the changes pushed, create a pull request from this branch to the main branch:
Clicking over to the Actions tab, you'll see the workflow running. It will fail due to the bundle size violation.
Because the bundle size check failed, the PR cannot be merged until the issue is resolved. This process helps maintain a healthy bundle size and prevents performance issues from creeping into your application.
Local Checks with Husky
In order to catch potential bundle size issues before even creating a pull request, we can integrate Husky, a tool for managing Git hooks.
First, run the following command to initialize Husky:
npx husky init
This will create a .husky/pre-commit file, and add a prepare script to your package.json file.
We need to add a couple test scripts to package.json in order to have Husky run them:
Then inside of the generated .husky/pre-commit file, we'll execute the build and test scripts:
// inside .husky/pre-commitnpm run buildnpm test
Now when trying to make a commit, Husky will run the build and bundle size checks before allowing the commit to proceed. If the bundle size exceeds the limit, the commit will be blocked:
Summary
By implementing bundle size checks using tools like BundleWatch and Husky, and automating them through GitHub Actions, we establish a proactive approach to maintaining performant Next.js applications. These techniques can also be applied to other types of checks you want to enforce in your development workflow.
Transcript
To set up a professional Next.js AppRouter application, you're going to want a couple of checks that are made both locally before you submit your PR to your repo, as well as in the repo. So we're going to walk through an example of that in this video. We're going to use a bundle size checker to actually check the bundle size of the application. That is a fantastic check that you are going to want to have on your Next.js application. An out-of-control bundle can be a serious performance problem.
So having the bundle size checked on every single PR is super valuable. And you'll learn that in this video, how to go and check your bundle size. We'll go and look at GitHub Actions, which is one way to run those checks on your PRs, if you use GitHub. And then we'll also look at Husky, which is a way to make sure that those checks are run locally before you even PR. So you're gonna learn three cool things in this video.
Let's start off by building our example application. So I'm gonna call this Next.js App Writer Application bundle size checker. It really doesn't matter the settings that we're gonna use. We're not actually gonna run the application. All we're gonna do is just check to see that the sample application that makes out of the box fits within our bundle size requirements, and then we'll go and add some outrageous stuff to it to max out the bundle, and we will then see it fail locally and also on GitHub.
So I'm just going to take all my defaults, and then I'll bring it up in VS Code. Now that we have our example application, we're going to create a GitHub repo and we're going to post our application to that GitHub repo. So over here on GitHub, I'm going to create a new repository. I'm going to call this bundle size checker, and I'm just going to make it private. I'm going to take the specification for remote, copy that, go over to my Visual Studio Code and bring up the terminal.
Now, next day, it's automatically initialized to GitHub repository for us. So I'm just going to go and add that remote to the pre-existing Git repository. Let's see if there's anything to check in. There isn't, we're good. So I'm going to then push that to master.
So I'll copy and paste the git push origin main, drop that into my terminal, and there we go. Now we're up on GitHub. Let's go take a look. Next thing to do is to go and add the bundle watcher. And this is the kind of thing that you're going to want to do early on in your application to create a baseline.
So what we're going to do is we're going to add something called bundle watch. Now there are a bunch of different options in this space. I'm just picking bundle watch as one of the ones that is off the shelf. If you want to use that, that's fine. If you want to use one of the others, feel free to go and research that on your own.
So the first thing I want to do is add this BundleWatch library to our application. Back in our terminal, I'm going to add that dev dependency of BundleWatch. Now that that's installed, we have to configure it. And there are multiple different ways to configure it. You can create a config file in the root directory, or if you want to keep your root directory clean, like I tend to, you can go and add the configuration to your package.json.
So let's go check that out. So over in our package.json, I'll just add a key for BundleWatch. In there, I'll give it the location of the files that it's going to check. We're going to use the .next directory. That's where our build goes.
We're going to check all the JavaScript files inside of the .NEXT directory and then we're going to set a threshold. How big do we want our chunks and our bundles to be? We'll set that right now at 100K. You can set that wherever you think is appropriate. Down the CI section, you need to find what the main branch is.
Ours is main, the default is actually master, and then whatever branches you want to track. So in this case, we're just going to track main. But if you have a development branch and a staging branch, you might want to add those. Let's save. And now let's give it a try.
So to give it a try we'll go over in our terminal and then do pmpm bundle watch. Okay now that failed because it can't actually find those files. So the first thing we really need to do is build our application. So let's build our application. As we look up here, we can see that the first page load is 89K, so that's under the 100K limit.
So we probably will be fine. So let's actually run our bundle watch. All right, we get a passing report here. It actually goes through and looks at all the JavaScript files and we can see the size and then the target size and everything currently is under 100K, which means that we passed. So now that we know that we're passing, we want to go and actually run this on GitHub.
So what we're going to do is we're going to create a GitHub action that's going to run our Bundle Watch on GitHub when we submit a PR. So first thing you need to do is add a GitHub directory. Now, actions in this case are called workflows. We're going to create a workflows directory and I'm going to create a bundle size workflow inside that directory. And it's going to be a YAML file.
So YML is the extension. You can name this file really whatever you want. I recommend naming it what you want to do, which in this case is checking the bundle size. So I'm going to bring in the YAML for this configuration file. It's in your instructions, and I'll walk through it step-by-step.
First, we're going to name it bundle size check. We're going to say that it's triggered on a pull request or any push to main. We're going to set the working directory to slash. If you have a monorepo, obviously, that's going to be within one of the app directories. Then we get the important parts around the environment variables.
We're going to set the repo owner as well as the repo name. We're going to grab the commit SHA from GitHub. We're going to say that our main branch is main. Then we're going to give it the BundleWatch GitHub token. So BundleWatch actually has a small service attached to it.
When you set up BundleWatch, you'll get a BundleWatch GitHub token. You're gonna wanna put that in the secrets. So I'm gonna go do that right now. I'm gonna grab this BundleWatch GitHub token. I'm gonna go back to our application over in GitHub.
Go to the settings, and then under secrets and variables, under actions, I'm gonna create a new repository secret. I'm going to put in my secret you don't get to see that. Now it's all set Let's go back to our YAML file and keep on looking at how that's going to work. Next we give it some permissions. We need to read from the contents of the repo as well as the actions, but we also want to write to the pull request.
So when the pull request fails, we'll write information to the pull request to say that it's failed. Let's go ahead now take a look at the job stuff. This is where we actually get the step-by-step of how we're gonna run this thing. So we're gonna start by saying that we're on Ubuntu latest, which we're going to use as the Docker image, and then we are gonna check out our code. We're gonna install nodes so we actually have something to run.
Then we're gonna set up PMPM. By default I think only MPM is in there. If you want to use PMPM or Yarn, you need to go and add those. Then we're gonna use PMPM install just like we would locally. Next up we're gonna restore the next build cache.
This comes in really handy if you're creating a lot of PRs. You can go and actually cache off part of the build. That's going to make for a faster build on the CI system. And finally, then we're going to build our next app. And then we're going to run our bundle watch command, just like we did locally.
All right, let's hit save and let's check it in. So I'm going to add these revisions, then I'm going to commit it, and then I'm going to push it to GitHub. Let's go have a look. So I look over here at actions, we should actually see our first action kicked off. Let's go and click on that, go and analyze, and now we can actually see it starting to run.
All right, We've successfully done our PMPM install. We didn't find any cache because we've never built here before. So we're gonna actually build the cache in this step, but now we're actually building the app. All right, it looks like we're done. Let's go check it out what happened here.
We went and did our build. It shows exactly the same numbers as it did locally. Then I ran our bundle watch, which actually did pass, and it gave us this result breakdown URL. We can click on that. We get this really nice report about all of the different bundle files and where they're currently sitting based against our maximum size threshold.
That's really cool. All right, so let's go and make this fail. So go back into our code. Now I hate to pick up material UI, I love that library, but that is what I'm gonna use to make the bundle size much larger by importing it the wrong way. So let's go and bring in material.
So material brings in material as well as emotion and emotion styled. And then over in our homepage, we're gonna bring in button, but we're gonna do it the seriously wrong way. Don't do it this way. So on our import, we are going to import the entirety of material as the material key. And from that, I'm just gonna pull out the material UI button, and I'm gonna use material.button to invoke that.
So what's actually happening is, normally, Next.js does a fantastic job of tree pruning, meaning that it goes and it finds all the code that you don't use in that application during its optimization build. This is actually circumventing that. So it's making sure that we're absolutely pushing in everything in material, which is definitely gonna bust out our 100 KB limit. So let's try this out. So I'm gonna do this locally first, make our terminal a bit bigger.
I'll do the build. We get some nasty little errors and then we scroll up We can see that the first load JS size is 254 kilobytes, so this is definitely going to go over. So let's run our local bundle watch. Now we can see the bundle watch failed. Let's go check out why.
So if we scroll up here, we'll see that we failed on some chunks. So we failed on this 403 chunk, and then we also failed on the overall page.js file. So that's basically the compiled JS file is bringing in all the material. That's 176K where we need to be less than 100K. But let's check it in anyway.
Now, the way that we're gonna do that is we're gonna create a PR. So I'm gonna create a PR by creating a new branch. I'll call it add material the wrong way. Again, this is the wrong way. Don't do it this way.
I'm going to add all my files to that and I'm going to commit it. I'll say don't do it this way. Now that that's all committed, I'm going to push that up to GitHub. All right. Now it's telling me I need to create a pull request for that.
So I'm going to option click there. And I'll just simply create the pull request. And that's now going to trigger our action. So let's go take a look at our action. We can see that Our don't do it this way PR has triggered the action and we'll go in here, check out the analyze.
Now we're getting a little bit of a build performance enhancement because we're using that Next.js build cache. We're getting the same error as NCI that we were locally, so that's a good sign. We're getting the same bulky page sizes, 254 KB, and we have failed our max size check, and in fact, we can scroll backwards and see that we now have a result breakdown. Let's go look at that. We can see that our normal page size is 160 KB less than where it is currently.
Really nice. And we go back and we take a look at the PR. We can actually see that that's failing. We can actually see that we've got the details there. This is absolutely fantastic.
So this means that no one will be able to PR into the main branch if they exceed the bundle size limits that we've set. And honestly, that is fantastic. You really want to set that up very early in your application to give yourself a nice healthy baseline for where your bundle size should be because bundle size has an immense impact on performance. Now it's kind of a drag that I had to burn CI to figure out that we had this issue. It would be great to actually run this locally.
So how do we do that? Well, we can install Husky. Let's go check it out back in our Visual Studio Code. I'm going to run mpx husky init. That's going to initialize Husky.
Now I'm just going to try and commit this. We can see that Husky is actually run. So it's missing a script for test. So if I go over here to our Husky pre-commit configuration, we can see that it's trying to do an NPM test. So let's go and add some tests.
We'll go over to our package.json, and we can see that in the script section, that Husky init is automatically added a prepare that calls Husky. So let's go and add our tests. In this case, all we're going to do is run that bundle size, which in turn is going to run BundleWatch. Now, if you had multiple tests, like you had an EDE test and a unit test, you'd want to add those as well, and then run those in whatever sequence you wanted. Let's hit save.
Now we'll try doing our commit again to see if this works. And now we were actually running our bundle watch and it failed. But what if I haven't built? So let's go and add in a build here and that will run build before running test. Try that again.
Alright it's doing its build and it fails. That just makes sure that you are actually checking the most recent build. You don't want somebody actually having an old build that didn't have in this case material in it and then saying well it works and then checking that in. So which would fail obviously in the CI but still you want to make sure that it's up to date. So that's why you might go and change your pre-commit hook or any of the other commit hooks.
Husky is a fantastic way to make sure that your code quality is where you want it to be before you make the PR. Well, there you go. We've taken a look at how to do bundle size checking, which is incredibly valuable, how to run that on GitHub, and also how to run that locally to ensure that your PRs are all good before you check them in.