Linting & ESLint Setup

[00:00:00]
>> The next thing we're going to add to our mono repo project here is linting. So we're on section four of the notes. And you have a little starter file here because I don't want you to have to write this es lint configuration from scratch. That seems kind of boring.

[00:00:19]
I'm going to despite Having put a bunch of this common configuration stuff in the packages folder, I'm going to ask you to put this in your workspace root. Why? Editors like VS code, kind of expect it to be there. And if you have it in other places, some editors may get a little.

[00:00:43]
Cranky and upset with you, and they won't give you that nice red squiggles underneath the things that violate your legit roles. So we wanna make sure that this can be found easily. And that is my only reason for putting this in the root of my workspace Compared to packages, this is a place where I'm trying to help you learn from my experience here because I have wrestled with this.

[00:01:10]
I've spent days trying to get this right in the other way. And take my word for it. It's not worth it. It's just not worth going there. Not the way things currently are We also need to set up es lint so I could. This is a good time to think about the question Eduardo just asked in the class which is, is this a workspace wide concern?

[00:01:42]
Or is this a per package concern? Well, I'm gonna tell you right away vs code wants to run one version of vs lint on your entire workspace. There is just no editor that is going to be accommodating enough to say you wanna use this version of vs lead for this folder, this other version for this other folder.

[00:02:07]
Not really a use case that this tool is built for. So that means this is a workspace level dependency. We have one version for the whole repo, not ever one version per package. And that means we're doing yarn, add w dw for workspace. We're gonna install eslint and then some plugins, typescript-eslint and then eslint plugin and TypeScript.

[00:02:43]
Yes, lint parser. Right. So, the flags here W is for workspace, D is for development dependency and let's let it go. Following our theme of really light and thin, per package dependencies. We still wanna have an eslintrc in each folder. But it's going to be super thin. That's all it is.

[00:03:21]
So we're extending, we're going to folders up now instead of one has a location of that more meaningful esrc that has all of our rules in it. So to levels up and then this parser options that must be specified on a per package basis, because, at least for the way TypeScript and es lint work together differences in Ts configs from package to package Like, are we parsing JSX or not?

[00:03:54]
Right? You have to inform the linter about that so that it can act accordingly. That is why we need an ES lint RC for each package. But it's the same insolent RC. That's the good news. So go ahead and grab this, copy it and paste it into your utils folder as well.

[00:04:18]
And then we never need to think about this file again. The only situation where we would start to think about it would be if. There were certain rules we wanted to apply on a per package basis. The final step we're gonna take just in the spirit of keeping Conventions nice and well established.Each packages, package JSON is going to get a lint task.

[00:04:54]
Right? So this we're saying whenever I go into a package and I run yarn, lint One runs esLint. I wanted to let the source folder and I want you to analyze JavaScript and TypeScript files. So we're going to have utils package JSON say that and the same exact thing in types.

[00:05:20]
If you're getting tired of making modifications to each of these files, one at a time I feel you. Were gonna solve this problem. I think next up, we should be ready to go. And what that means is it's time to take it for a spin. So let's enter a package and run yarn lint.

[00:05:49]
Okay?, that's done. I'm not sure if it's not finding anything. I mean I usually like to see it find stuff, there we go. It found something left us a little clue. So we would see the difference between es lint did nothing, versus it analyzed things, and it found a problem.

[00:06:09]
So it's telling us that I'm returning something here. That's it. It doesn't like and look at this. I'm getting a little tooltip here. It's not just a tooltip Prometheus lens, it's a tooltip that uses one of the plugins that I installed. So this is a pretty compelling bit of evidence that VS code is happy with the way we've set it up.

[00:06:30]
So we're seeing this on the command line. We're seeing it in the editor. Everything's in sync, we can trust that our tools are working properly. In here, I can just add these two words. If you don't, if you're not super, super familiar with TypeScript, don't worry about what these mean that they do shut ESLint up.

[00:06:54]
Alternatively, we could just say disable the rule for that line. But this is the right that this is the right solution. And let's run it in the COI just to prove that everything works and it should. We're good to go. We now have linting in our two packages.