Running Quality Checks in your Monorepo

Share this video with your friends

Send Tweet
Published 2 years ago
Updated 2 years ago

All of our applications and libraries have test and typecheck commands already written inside of them. We are able to run both the test and typecheck commands all at the same time as well.

This has a downside. They don’t run at the same time, it’s just one after the other. To make them run at the same time, we will implement concurrently again.

Alejandro Ñáñez: [0:00] We already have Jest and the TypeScript compiler set up to look for any possible errors in our project.

[0:07] Let's take a look at the package.json. In the utils project, we have a test command that runs Jest, and we also have a typecheck command that runs a TypeScript compiler against certain files.

[0:20] The same is true for our project, so let's take a look at the dashboard. We have this test command that runs the tests for the dashboard project, and the same for the typecheck command. If we open the blog, which is a Next.js application, we'll see that we have Jest, and we have our typecheck as well.

[0:43] It also means that we can run all the tests in one command by running npm run test, and then we have the ws flag. Here, you can see that we're running the test in the utils project, the tests in the dashboard project, and the tests in the blog project.

[1:00] The same is true for the typecheck command. Surely, we are running the typecheck command in every project, but this has a downside, we are running all these tasks sequentially, so we run the blog typecheck command. Once that is done, we run the typecheck command in the dashboard and then we run the typecheck command in the utils project.

[1:26] We can improve this by using concurrently. Here we are in the package.json file in the root of the project and we are going to duplicate these commands, so let's make a few of them. This dev utils is going to be called...Let's change this to run the tests. Now, let's change this script to run the typecheck command. Let's add a missing comma here.

[1:53] We're going to create the check script, so this is going to use concurrently, right? Here we are going to escape some quotes. Let's do that here. We are going to run npm call on the test, right? Then we are going to use the * and what this is going to do is that it is going to run all the npm scripts that start with test: .

[2:20] Let's duplicate that and we are going to do the same for typecheck. We are going to add a flag that is called killOthersOnFail. This means that we're going to exit the check process if any of the tests or any of the typecheck fails.

[2:43] We're going to run npm run check. It finished, so let's take a look. It is running test for blog, it is running test for dashboard, it is running typecheck for utils, and so on and so forth. In the end, everything passed, so we don't get any error. We're going to change this 4 for a 5 so the test fails, and we're going to run npm run check again.

[3:12] Let's scroll up a little bit, and we see that this test fails in the test utils. It says that basically, we exit earlier because the test in the utils package failed. This is really useful in a CI environment because you don't want to run all your checks if one of them fails. You want to exit early.

[3:35] To recap, we have one npm script to run the test in each one of the projects, and we have one npm script to run the typecheck command in each one of the projects. With all that in place we have created the check npm script, and this script is going to run all the tests and all the typecheck scripts that we have below in parallel.

[3:58] We also added the kill or some fail flag so we exit earlier, if any of the tests fail or any of the typecheck checks fail.

Ben Brown
Ben Brown
~ 2 years ago

Your missing information in video 9 around vitest, the tests just kind of appear from nowhere

Alejandro Ñáñez
Alejandro Ñáñezinstructor
~ 2 years ago

@Ben, hey! I didn’t dig deep into how to setup tests in Vite, or in any of the other applications/libs as this course was not meant to be about testing and that’s a whole topic itself! But setting up Vitest shouldn’t be hard,

Here’s how I did it for the first iteration of this course https://github.com/alejandronanez/turborepo-egghead/blob/main/apps/blog/vite.config.ts

and here’s their official docs: https://vitest.dev/guide/

I can share the code from the course in a couple of weeks when I’m back from vacations. 👍

Ben Brown
Ben Brown
~ 2 years ago

Perfect thank you!

Pedro Serapio
Pedro Serapio
~ a year ago

Could be interesting to explain where all vitest stuff is coming from. Probably remake the video.