ESLint

[00:00:00]
>> Brian Holt: We are gonna talk about linting. Who is pumped about linting, get out. [LAUGH] No, I'm just kidding. [LAUGH] Just kidding. I got mixed feelings about linting. I've gone all over the map from unlinting. If you watch complete intro to React V2, there comes in this different Brian Holt character that's just like we're gonna limp the hell out of this project.

[00:00:28]
It's gonna look like one person wrote it and I was very much on that train of like, let's let the tools control you. And I've come all the way back the other way and if you like watch react to be seven. You get this hippie brand. It's free love and no linting, right?

[00:00:44]
Where I'm just write whatever code you feel dude. Now I've come back more to help me catch very common and very easy to miss bugs and otherwise leave me the hell alone. This actually just kind of applies to my general thought process on building dev tools of your developer has something in mind that they want to express in the code.

[00:01:10]
And don't interrupt them unless they're actually going to, unless you're helping them, right? Just getting someone to write code in a certain format because you feel like it is adding more and more friction and it's more distance between someone expressing their idea in code. And so that's why I'm much more careful these days to be very light on the linting side and just if it's not important, don't do it, right.

[00:01:40]
Okay, so we're gonna do prettier and people frequently ask me what's the difference between linting and or ESlint and prettier? ESlint is linting obviously. Linting is much more l semantics and syntax and content focused where you're saying things like. You have to alphabetize all of your imports, which is one of my very least favorite rules that you can enforce in ESLint.

[00:02:15]
But it's things like that, it's things where you're enforcing an opinion on someone it could be totally valid code but you're saying, I don't want you to do this. One of the ones that I do find useful is don't use any globals, right? Because usually that means that you misspelled something, so it's gonna reach for a global as opposed to finding the one that you actually intended to name it, right?

[00:02:36]
Prettier is just formatting. It's just white space and new lines. It does not enforce anything about the code, it's just making sure that all of the white space ends up in the right place. That's all that prettier does. There's some overlap that you can basically have ESlint do some of what prettier does.

[00:02:52]
But if we're using both tools, prettier is much better formatting. Leave the formatting to prettier, just have lint for all the linting rules. Yeah, Mark?
>> Mark: Have you heard of Oxlint?
>> Brian Holt: I have. I might even mention it down here,I do, look at that. I think this is actually supposed to be a zero.

[00:03:14]
No, okay, no, I was right it is. There's two projects to keep an eye on. Here is ox lint and biome. Biome used to be called Rome oxlint, I think is, this is all written in rust. And there's, I think, a couple of other projects. They're so new, and they both really lean on ESLint anyway, for its rules.

[00:03:40]
So I'm interested, I'm keeping an eye on it. The creator of Vue and vite, Evan Yu started a new company around oxlint and vite and all these tools. So I'm interested, but they're still so new. In this course, I'm trying to teach you to be job ready today with React and I'm not teaching you anything that's that far out on the edge.

[00:04:02]
So look at it, admire it. Help but if you're going to your day job, ship, be a slint it's just the safe choice right now, and it's a perfectly good piece of software.
>> Brian Holt: Okay, yeah. A good example here is you want a force people to never use with.

[00:04:21]
If with is technically valid JavaScript, it was an ES3, right? But you never wanna have with in a modern code base, it would just make zero sense, right? So you can have ESLint say, hey, you're using with. No one uses with, please stop doing that. Okay, I'm gonna have you install ESLint and these tools at specific versions.

[00:04:44]
>> Brian Holt: The reason why I'm gonna have you do that now and for the rest of the course is, this course is a moment in time, and they're definitely going to release new changes and breaking changes. And I want people to stay on tools that I have verified work together.

[00:04:59]
So, feel free to try and install later versions of ESLint or React or whatever you want, but just know when they release new minor or major versions of these things, it's probably gonna break, right? There is a massive difference between ESLint 8 and ESLint 9. React V8 uses ESLint 8, and I had to rewrite this entire portion of the course because it totally changed, right?

[00:05:23]
So, go ahead and grab this, I will just copy and paste it directly,
>> Brian Holt: Go to your project, and we're just gonna install -D, right, for development. eslint@9.9.1, eslint-config@9.1.0, and globals@15.9.0.
>> Brian Holt: Cool, again, you'll notice in our package.json, we now have a bunch more devDependencies.
>> Brian Holt: Cool.
>> Brian Holt: Now,
>> Brian Holt: We're gonna create a file in the root of our project.

[00:06:11]
It's gonna be called eslint.config.mjs
>> Brian Holt: Now every version of this course previously used eslintrc.json, that is no longer supported. You actually have to do it this way now and you might be asking, why is it mjs? Because otherwise it assumes it is common JS, and we want to use ES modules.

[00:06:36]
So the mjs here means that we're gonna do import and export as opposed to require, right? So that's why.
>> Brian Holt: And we are gonna start writing a little ESLint config, import js from eslint/js, import globals from globals and import prettier from ESLint config prettier, all right? This is one of my favorite tricks with just VS Code and TypeScript in general.

[00:07:23]
This is not TypeScript, but I still love completions when I'm writing code, right? So you can say type,
>> Brian Holt: import
>> Brian Holt: Eslint.
>> Brian Holt: .linter.config array. Now, you can see the two stars here in the slash. This is a comment, right? But this is letting VS Code know this is this type.

[00:07:57]
Please give me all the type completions for this. So now I can say export default and give it an array and now I'm gonna have proper type completions inside of this. This is totally optional. You can totally leave this off if you're in something like sub yeah, sublime or text made.

[00:08:18]
I don't know why you're on text made that I have questions about that, but you probably wouldn't use this. This probably wouldn't be very helpful for you, but for VS code specifically, this is really quite nice. So now I can say js.config and I'm gonna give it.recommended. So we're gonna export this array of rules for eslint.

[00:08:43]
This is their new flat configuration style. I find it confusing. [LAUGH] But this is the way you have to do it now. So we're stuck with it. So you export multiple different configurations, and it kind of builds one on time upon the other. So this will be executed, then the second one, then the third one, then the fourth one.

[00:09:11]
So the lower it is in the list, the last it is executed. So one thing is this prettier config always has to be last. Just keep that in mind, just drill it into your brain. The prettier config always has to be last. Why is that? The prettier config, all it does is turn off stuff.

[00:09:32]
It doesn't add anything new. All it says is, don't check formatting. Don't check this kind of formatting. Don't check news lines, don't check any of that kinda stuff. All this does is turn off formatting, which is useful. Otherwise you get, eslint yelling at you that's like, hey, you didn't format this correctly and this will prevent it from yelling at you for stuff that doesn't matter.

[00:09:55]
Okay, we're gonna put our configuration here in the middle, so js.configs.recommended. This is just a very small subset of non-controversial ESLint rules, right? They're just purely value-add. I've never had a problem with the recommended one. If you want everything that ESLint can check for, you can do .all, but you are a glutton for punishment if you're doing that, it's going to check things that you don't care about, I promise.

[00:10:21]
So you know what? Again, I'm not your mom do whatever you want, but I'm not going to put that in there because it annoys me so quickly. Okay, we're gonna tell what files so that, okay? Again, this type thing right here, the reason why it knows here, this files is from that comment up there, right?

[00:10:42]
Which I find extremely useful. Okay, and I'm gonna tell it to check for everything to do with .js files. And if you want to get ahead of the game here, we're eventually going to be doing JSX so you might as well just check that in there as well.

[00:11:03]
If you're doing TS and TSX you put that in here as well, right? So, okay, language options.
>> Brian Holt: We are gonna say here's the globals that we want you to check or be aware of where do globals.browser and globals.node. Why this? It's so that when we go into like here, we can say things like window or document, things that are globals in those environments.

[00:11:46]
If you don't import and add those, it's going to be like, hey, I don't know what documents is, right? So that's what globals is. Sorry, back in here. This is just the spread operator, right? So we could do some sort of like object out assign here, right? But we can just use the spread operator.

[00:12:06]
This is a little bit cleaner. This is just going to be the union of browser and node here, right? As one object. That's all the globals that we need for this project, parser options.
>> Brian Holt: ECMA features,and we need JSX,
>> Brian Holt: And I think that should be good for us for a little bit.

[00:12:36]
>> Brian Holt: This is just going to allow us to use JSX, which we're about to do, right? Without this, ESN is still gonna be okay cuz it can parse jsx, but it's not going to understand how React is working and how it's importing things correctly. So this becomes important.

[00:13:00]
>> Brian Holt: All right.
>> Brian Holt: So again, let's go back into our package.json and make it so that this can run eslint. We're gonna say lint and now we can just say eslint. You used to have to put this long string associated with it but now it reads Config properly and you don't have to do that.

[00:13:28]
>> Brian Holt: So now if we come in here and we say npm run lint, you'll see a bunch of these errors, right.
>> Brian Holt: And my notes here say that, this should fix it if you say ESPN or ESPN, wow. Yeah, something on the mind, I guess. Run lint ----fix.

[00:13:53]
So this -- just means, hey, I want to pass this into eslint. So this will actually end up running eslint--fix. If you don't put this dash dash in there, it's going to apply dash dash fix to npm. Which doesn't make any sense right? So that's why you need the dash dash.

[00:14:14]
Yeah I didn't think so. So, [COUGH] what's something that I could fix automatically? I don't remember. Some of your linting errors can be fixed automatically, it contains transformations that will just fix some of these things for you. We have nothing to fix right now, so that doesn't really help us that much, but that's kind of a fun trick to do sometimes, another one if you're debugging this is debug is super useful.

[00:14:44]
You get a lot of output of like eslint for working. It's telling you everything that it's parsing, it's telling you all the errors that it's found. It's telling you all the rules that it's loading. So you can see these are all of the checks that it's running, which is Kind of cool.

[00:15:03]
Yeah so, here's a good one, no debugger. Let's say, I don't know if you've ever used this before. VS code has a very useful debugger built into it. We won't be using it today, but like I use it quite a bit for my node projects and. So now I think if I say npm run lint, it should give me an error around not using the debugger.

[00:15:30]
>> Brian Holt: Yeah, unexpected debugger statement. It'll catch things like that. You want this to error, right? Because I'm gonna put this in there, and I want this to stay here while I'm using it but I don't ever want to shift this to production, right? So that's something that lint will catch for you.

[00:15:46]
Yeah, let's install the extension. There is an ESLint extension, I will say that of the common extensions I recommend people install this one is the most finicky. Sometimes the ESLint one should look like this. It's official from Microsoft, it just gets bent out of shape sometimes and so if you find that it's not or it's highlighting something that it should or not highlighting something that it should.

[00:16:17]
A good restart will usually fix a lot of stuff either of VS Code itself or the whole computer, I don't know. Definitely one of the ones that annoys me the most and sometimes I just end up disabling it because it's so annoying. The purpose of the npm script you wrote is only if somebody doesn't have prettier installed in their editor, correct?

[00:16:41]
It's amongst the reasons that I would do it, the probably the chief reason, is so that I can now run it in CICD, right? So I can run it as like a GitHub action, so then it won't check in my or it won't deploy my code, if it's like failing lint or failing prettier.

[00:16:56]
That's probably the biggest reason, because almost everyone that I work with or have worked with, has some version of Prettier or Lint built into their editor and they just fix it on the fly. And there's a few holdouts that'll just run it right before they commit, right? So those are the two chief reasons I do it.