Enterprise TypeScript

null, undefined & boolean Operators

Enterprise TypeScript

Check out a free preview of the full Enterprise TypeScript course

The "null, undefined & boolean Operators" Lesson is part of the full, Enterprise TypeScript course featured in this preview video. Here's what you'd learn in this lesson:

Mike applies ESLint rules and increases the strictness of the files in the utils folder. Similar to defining an additional tsconfig file, the new ESLint rules can be defined in the overrides object and the rules can be scoped to a specific directory.


Transcript from the "null, undefined & boolean Operators" Lesson

>> All right, next up, and we're gonna just do another small-scale pass here where we're just focusing in on a subpart of the app. We'll focus on the same subpart, just like the utilities folder. This is where we're gonna start to apply ESLint rules and crank up the strictness from that standpoint.

And it's a combination of TSConfig and ESLint. So we'll enable strictNullChecks, exactOptionalPropertyTypes in TSConfig, and then we'll enable this ESLint rule. And the new thing we're learning here is, we already know how to focus a set of compiler flags on a folder in a project, right? We put a new TSConfig in there, and then we can run tsc -P and point to the folder and it'll just compile that.

We did that with no implicit any, right? We just did that on the utils folder. We'll do the same thing here, it's a little different. But this is another great skill to have where you can sort of tighten up strictness locally, and then hold your ground, right? You can get it into a state you want it to be in, and that's the new baseline.

Those are the new rules for that part of the project. All right, let's get started. Let's first make the compiler setting changes. So strictNullChecks and exactOptionalPropertyTypes. So we're gonna go back to our TSConfig file in the utils folder, here it is. strictOptional, exactOptionalPropertyTypes, there it is, true. And then the other flag is strictNullChecks.

True, so we already know how this works. We're gonna run tsc -P, point to this folder, and it'll tell us what's up. Nothing, we got by clean this time. There's nothing, we weren't able to turn these flags on. And through what we've done already today, we may have addressed all of the things that could have made this fail.

So let's focus on the ESLint side. I'm just gonna grab the name of this ESLint rule. And we're gonna go to our outer ESLint config. So this is a little bit different. It does not involve us having to create a different config file for this folder. And that is because ESLint gives us this overrides array, starts up here, right?

Look at how many lines of config we have inherited. Override is where a lot of important stuff happens. And the idea behind overrides is you specify some set of files or folders, you can use globs here, right? And you can define rule sets that are used for those files.

You can enable or disable certain rules that happen here. And so, we're just gonna create a new override for the utils, like source/utils, and we'll add this one rule to it. And we'll be able to run yarn lint, it'll just treat that folder in a more strict way.

You just add it right at the top. So it's a new object, and we could say files. And we'll say its source/utils/**.ts, yeah, that's great, something like that. You could even have a little set of braces here to say tsx, mts, cts, any kind of TypeScript file. A React TypeScript file, a common JS TypeScript file, a native ES module TypeScript file, this should apply to all of those.

And then we're gonna say rules. Strict-boolean-expressions, and we'll say error. Generally, I think there are a variety of different things you can use for what you put over here. I tend to use error, warn, and off. I think you can use numbers as well, like 2, 1, and 0, but this is how I tend to do it, more readable.

Okay, let's run yarn lint and see what happens. We got a couple errors, or a couple lint violations, two problems in one file. So let's check it out, what's up here? This rule requires strictNullChecks compiler option to be turned on in order to function properly. Hmm, let's bump ESLint and TypeScript.

Hey, it's better now. Don't forget to try that first. I've chased my tail so many times just to realize that turning it off and on again caused something to pick up new state here. So, great, we do have TSConfig with strictNullChecks turned on. ESLint, in fact, is gonna check to make sure that requirement, which is necessary for this rule we just started to use.

It's gonna make sure that the TSConfig lines up for where we have that rule scoped. They're both on the utils folder, so we're okay. But it would bug you if you sort of cast a wide net with the rule, but strictNullChecks is only enabled for a couple files.

It will tell you about that. Okay, unexpected nullable string value in a conditional, please handle the nullish and empty cases. And it's reminding me that this is a nullable thing, right? It could be undefined, and I can handle that this way. Instead of using or to express my default here, I can use nullish coalescing, question mark, question mark.

Down here, This is an unknown, error is an unknown, we typed it as such. And it's saying, we need a comparison, or we need a typecast of some sort. So what should we do here? It's another trick question. We have some options. I mean, at this point, we kind of just wanna serialize it, we wanna coerce it to a string, whatever it is.

Cuz we've already checked to see if it's an instance of Error. We have to return, the whole point of this is to return some stringish value. We cast it to any, that's not gonna be great. How about that? Not new, pass it through the String constructor. We solved this problem, by the way, earlier in the course.

Cuz this is one of those functions that's in our little library. We're gonna switch and start depending on that library in just two chapters from now, right near the end. Okay, so I think that's it, I think we should be good. yarn lint should return no errors at this point.

So that's an example of us being able to focus linting in and to be more strict on a couple files or a couple folders. And I think this is even better than TypeScript, cuz imagine we started to take on the data folder, right? We could just add it to this files array, source/data/something.

We don't need to have all these TSConfigs floating around. We could just kind of do it that way. You could do that with TSConfig as well by saying, I include a bunch of different stuff, but it's not as nice as this. You don't have as much fine-grained control over like, disable this one little thing, right?

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