Enterprise TypeScript

Configure ESLint

Enterprise TypeScript

Check out a free preview of the full Enterprise TypeScript course

The "Configure ESLint" Lesson is part of the full, Enterprise TypeScript course featured in this preview video. Here's what you'd learn in this lesson:

Mike adjusts the ESLint config file, adding TypeScript-specific rules and specifying the TS config file location. The lint command is run, and initial linting errors are fixed in the index.ts file.


Transcript from the "Configure ESLint" Lesson

>> We have this nice eslint rc.js file. This is our eslint config. We're gonna make a couple changes here, in the extends array. So it's giving us like the recommended set of eslint rules. That's, that's what extends means here, right? It lets you take in sort of rule sets as a starting point.

And then you can turn individual rules on off, after opting into a rule set, so it's sort of like what's your baseline which you can then tweak. So this is just general recommended eslint plug, like best practices, which is for JavaScript and TypeScript code. There's a TypeScript eslint recommended set of things.

I would recommend if you're gonna include this one, you always include the second one as well. It sort of overrides some rules. In eslint, like, for example, no unused variables. TypeScript has a way of doing that through the compiler. If you remember, in our ts config we had like no unused down here, right?

So some of these things we want to rely on TypeScript handling for us. So, it makes a lot of sense to turn this on. There's there's a third one we want to enable, plugin at TypeScript. There it is. So it's the same one is above. You're just adding these words.

It's Typescript recommended, requiring type checking. And the point of this rule set, it's to include rules that actually use type information in order to perform linting, right? For example, you could have rules about forbidding explicit ns, and you can only find that information through type-checking. So I tend to enable this one as well.

Next, we're gonna and look at the parser options. So this is another important change here. We have to tell because eslint is using TypeScript to analyze code and to provide information about types, we have to tell it where the tsconfig is that we're using. So we're actually gonna just write project true and we'll say tsconfig root dir and then dir name.

This is something that's available in like all Node js modules, it's just a global value that's available. It's the current directory of where the files located. So this will help eslint find our tsconfig. Okay, two last adjustments we have to make. There's a section called is do we have it populated yet?

Yes, we do. Overrides. So the purpose of overrides is to describe local parts of our project where rules may apply differently. So in this case, I've got this was part of what was generated for me, right, I didn't write this this was like when we did eslint--net. This is part of what that's been out.

It's set up some special rules that apply to this file that we're looking at right now. Node true is what's letting us safely access dirname. We're gonna add another override here. It doesn't really matter where you add it, in this case it doesn't matter, but just remember these are processed from top to bottom.

So in cases where overrides may overlap, like if you said, here's a rule for all typescript files in the project, and here's a rule for all files in this folder. Sometimes you might meet both conditions and so you wanna arrange your override such that the first one that you want to be checked is higher up in this array.

So we're gonna say file, Tests, and I want to all TypeScript files within a tests folder that we're about to create in the next step. Then for env, I want node true, and not Mocha true, but Jest true. Jest, if you've ever used it before, it comes with some function names like describe and this will make sure that like we get the types for jest there.

And one last thing here in the rules for eslint itself and this override here we want to add two more things. You can copy this right from the course website, oops, that is weird. I'll just go to the course website over here, trying to copy paste from my iPad like that's gonna work seamlessly.

Here we go. These two lines, and I'll explain what they do in a moment. Okay, the first line it this actually disables, remember that that eslint entry we added to extends requiring type checking this thing up here this disables that. So it's nice to be able to say look across my whole project in general I want to set of rules that require type checking enabled, but in this one place, turn them off.

I just don't want it yelling at us about our eslint rc file and then no unsafe assignment. This is what would let you like assign an any to a property We're turning that off. And we're now ready to lint, yarn, lint. We should see some errors. Two problems.

We've got two problems. This means it's working. Nicely formatted indications of what's going on. So let's in vs code, on a Mac, at least I can command click and it'll take me to the file index.ts. Sorry, I'm gonna save this here. And let's find, I'm looking at this little red dot in my gutter here.

Okay, here's the problem. What's the problem? Invalid operand for a plus operation. Operands must be a number or string. And what type is it? It's an empty object. Folks who have taken the intermediate TypeScript course, what's this type? Actually, the easier question is, what can't this type be?

It's almost a top type.
>> Can't be null or undefined?
>> Can't be null or undefined. So it's any non-null or non-undefined value. You know, eslint's telling us this might be an error. This seems weird. I can get rid of this error by deliberately coercing it to a string.

Do that, there are a couple of other things I could do, but if I said, yeah, I do want this to be serialized to a string. The string constructor takes in an any, and so it's perfectly happy to take this value in. Save that file. Let's run the linter again.

And there we go. It seems to pass. This is a great time to make a git commit, because we have linting working in our project now. So we had a couple questions online. First thing I wanna point out is, somebody had trouble where they were seeing the linting experience that I saw.

In their terminal right where they saw these, it's out of my buffer now, where they saw you know the lint errors and the lines and the files that was all coming as part of the terminal output. When they ran yard lint, but they didn't see the equivalent experience in their visual studio code.

And this is pretty common when you are just adding linting to a project. So one of the big challenging things in a large scale TypeScript project is watching various files for different things gets quite expensive. So VS code doesn't pick up immediately on the fact that like there's a new TypeScript file here and there's a new eslint config and eslint has been installed in this little folder.

The solution for that I'm doing command Shift+P, this usually solves the problem. You restart the eslint server, you're turning it off and on again, and at that point, it's gonna begin by taking a top-level examination of what are we dealing with here, and often that'll get your CLI commands, eslint.

And your in editor red squiggles under your code, it'll get those in sync. Where you're seeing the same things, which is great. VS Code has this great problems tab where if I were to have some problematic syntax here, it points it out here. It's important to keep your in editor eslint working well.

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