JavaScript and TypeScript Monorepos

Adding Tests with Jest & Babel

JavaScript and TypeScript Monorepos

Check out a free preview of the full JavaScript and TypeScript Monorepos course

The "Adding Tests with Jest & Babel" Lesson is part of the full, JavaScript and TypeScript Monorepos course featured in this preview video. Here's what you'd learn in this lesson:

Mike adds testing to the monorepos using Jest, builds a Babel configuration in the packages folder to ensure one source of truth for the configuration, and copies the configuration to both the types and utils folder. Jest allows developers to have one unique solution that solves issues for all packages. In this segment, a Yarn script is defined for the purpose of running the Yarn test command within any package of the workspace.


Transcript from the "Adding Tests with Jest & Babel" Lesson

>> Going to be adding testing to this mono repo and we're just going to be using jest it. It is a good choice for for something like a mono repo because just can handle TypeScript files JavaScript files JSX, TSX it can handle whatever you throw at it. And I wanna have one solution when I'm working with mono repos, one solution that solves a problem for all of my packages.

I do not want to find myself using mocha for some things, and Q unit for other things. And just for some other things, That just introduces a lot of complexity. And if you're working on this with the team, they need to basically learn all of these different tools, that's bad, right?

Extra mental overhead, extra work, extra things that can break. So we want to have the thing that solves the problem, wherever we may need it. Just works pretty much out of the box. With a small exception. It needs some Babel plugins so that it can understand TypeScript, for example.

So what we're gonna do is install some Babel plugins in each of our packages and those are preset and preset TypeScript yarn add as a dev dependency. So we're just gonna run this preset env preset TypeScript And then I'm gonna run the exact same thing in the utils folder.

Now, following our convention of one meaningful source of truth I want to have a Babel config In my packages folder that every package can extend from, because they're pretty much going to be the same until we introduce some react components. All we need to worry about is understand JavaScript and TypeScript.

Right? So We can have one place to define that. I'm gonna create a new file, it's gonna be called dot Babel RC. And if you look in your course files under step, I don't have one for you here, because this one's pretty easy. [LAUGH] So here it is.

presets. And then you have an array. This is in the notes free to copy and paste. I just don't have a file for you to just drag. So we're gonna say preset and the purpose of preset end is for you For Babel to transform whatever it needs to transform based on the build target environment.

So we're going to say, look I'm writing my code the way I want to write it. I have lots of modern language features in here, how it's in TypeScript. But I want you to sort of dumb it down. So that it works in Node 10. Good also put like iE 11 here, and it'll polyfill whatever it needs to polyfill iE 11 doesn't know about async await node eight doesn't either.

No date is end of life. So we're not building for that. But this will automatically, you know, simplify things down based on the build target you specify. And if you're interested in the different types of targets that you can use here, there is an NPM package called browser list.

And that is the thing. All build tools typically refer to like that is the thing that's used to provide expressions for which target you're aiming for. So that you can have strings like last two chrome versions, or all browsers that have Greater than a quarter of 1% market share.

And that's sort of a moving target right as market share changes. Like ie 11 drops off. Well, the day that happens the day it's less than a quarter of a percent. Your builds will get smaller, you don't have to worry about turning things off on a per feature basis like I can use a sync await now, it'll just happen for you.

So it's really, really convenient. So that's our preset and then this second value here. Oops sorry it has to be in this in this array. Babel, TypeScript, preset TypeScript with a comma because that's how arrays work. So in the end, your Babel RC should look like this. We are building for node 10 And we want to strip out the symbols that are specific to TypeScript, leaving only JavaScript behind.

This is our single place where we're gonna defined this. Following our convention, we're gonna create a very simple. Babel RC in each package. That's it. So create one of these at the root of your utils folder, and one at the root of your types folder.I'm just gonna copy And paste.

So I've got Babel RC. And then here's actually, so you don't need to see both of those because those are both very trivial. So this is the meaningful one, which is in the packages folder, and then each package has one of these. And you never need to think about this one again.

Now the exception would be, let's say that some of your code runs on the server side some runs on the client side, then you might have a different Babel RC.Like the the bar is much. You need to dumb things down much more for IE 11 compared to node 10.

Node 10 is the oldest supported node version right now. Ie 11 unfortunately is still supported and it is much, much older. If we've done our job right, let me just do a quick check of my notes here. All right, I don't see anything else should be good. Should be able now to just just run.

Just Nice, our tests pass and I see that there's some meaningful, meaningful output here. Let's see if it also works in our types folder. Past looking good, I was easy, just is really easy to set up these days just to put the icing on the cake here Let's create an NPM script so that we can just run yarn test.

And this would let us we're trying to define a common convention here because this will pay off later. So certain packages may have extra testing steps that need to happen. For example, At LinkedIn, one of the one of my little pet projects is visual regression testing, where you take screenshots of components.

And as you make code changes, you take new screenshots and you compare them. So this can catch things like CSS bugs, which are otherwise quite difficult to catch. So test might mean something different for that package. This is the value of having a convention where you can just say, Look visit any package and just run yarn test.

And it's run whatever it has to run, whatever test means for that package. So we'll say in this case test just means Just run jest. We're gonna add this to both of our current packages. So there it is in types. And there it is in our utils package, and that's it.

We have testing, we can run yarn test in any package within our workspace.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now