Configuring ESLint & React

[00:00:00]
>> Okay, so let's talk about this ESLint error momentarily. It's saying, hey, you don't ever use app. So no unused variables, right. This is the same thing that would complain if I said const x =5, and I just never used it. It's gonna say, hey, you create X but then you never use it.

[00:00:18]
Why did you create x in the first place? It's because ESLint up until now does not understand JSX, right. It's saying like, hey, you imported pet but you never used it. You created that, but you never used to despite the fact that we use pet here and we used app down here.

[00:00:36]
We need to augment the ESLint to be able to understand JSX. So, let's go ahead and do that really quick. And it's a bit of a pain so bear with me for a second. I promised you no more tooling and then I lied. NPMI -D and we need to get quite a few here.

[00:01:00]
ESLint -plugin-import and then you need at 2.26.0. By the way, you don't have to copy you can literally just go copy this from my notes as well if you don't want to do that it's here in JSX under ESLint react. Just run this one right there. I'm gonna type it out so people can see it.

[00:01:29]
But I invite you please to go be lazy. ESLint-plugin-JSX-a11y accessibility. At 6.6.1 and ESLint -plugin-react@7.31.8. Just 76 packages so no big deal. Okay, and then we got to update our ESLint, I'll see a little bit here. So, Put these on different lines would be a little bit easier to read.

[00:02:23]
Again, the order here under extends does not make a big difference. Just make sure prettier is last. Plugin:import/errors, plugin:react/recommended and plugin:jsx-a11y:, sorry, /recommended. So this notation means that you're gonna go get the plugin, which we installed all these plugins for es6, right? Plugins just augment ESLint etc. The extensive set of rules, right.

[00:03:08]
And the plugin is like adding additional capabilities to ESLint. These are all just the recommended things. Again, these are gonna be the kind of things that are not very opinionated, except I guess maybe accessibility but I'm gonna argue that's an error anyway. These should just be things that are very uncontroversial things that you should always do, okay.

[00:03:34]
And then we're gonna turn off a couple of rules here. We definitely don't need prop types. Prop types are kind of an old thing for react. If you don't wanna use TypeScript, but you want validation in your code, like a prop validation. You can use prop types, which I'm going to say is this isn't an array.

[00:03:54]
Sorry, this is a object. Yeah. Prop types are silly. Don't, don't do prop types either use TypeScript or use nothing. And then react/react-in-JSX-scope to be zero as well. What is an array? No, this is yeah sorry this is not meant to be plugins this is meant to be rules.

[00:04:29]
Okay, so sorry, rules react/prop-types:0, and react/react-in- jsx-scope. This used to require that anywhere use JSX imported react which used to be the rule. But with react 17 we don't have to do that anymore. Rather with a recent version of Babel, it doesn't matter anyway. Zero means this is not an error anymore.

[00:04:53]
Please ignore this rule. That's what zero means, I think one means warn and two means error. So that's why it's zero okay, sorry now plugins we have a react plugin. We have an import plugin import just allows ESLint to follow imports, right. So it can see if I'm exporting something from this file, and I'm trying to import something different in a different file.

[00:05:25]
It'll find that error across imports and exports. That's what import does. And then jsx- a11y. This is like if you put like a click listener on something that's not like a button, it's gonna say like this isn't accessible. It'll catch a bunch of those like very simple straightforward accessibility errors.

[00:05:48]
I like it cuz accessibility is hard for the most part. And so this will help me with basic things. Okay, that's all good emphasis good. We need to add one more at the bottom which is settings Okay, ESLint wanna know what version of react you're using So you can just say, go figure it out yourself.

[00:06:14]
So detect says, hey, go read my package.json and figure it out yourself. I don't know why they don't do that by default, but they don't. And then for the import/resolver, If it's like right now it's saying hey pet doesn't exist. That's because right now ESLint is only configured to look for.JSX files we need to tell it you also need to look for JSX files.

[00:06:44]
So, here you're gonna say node. Extensions and you have to give it an array of .JSX and .JSX. So this is saying, please also look for JSX files. Okay, this isn't file that you now see in front of you is what I use on most of my projects.

[00:07:17]
This is vanilla react ESLint for me, right. And I think it's very uncontroversial and in the opinion set of forces. Having worked in DevTools for and like developer infrastructure for a long time. I'm very cognizant of the fact that I don't want to annoy developers unnecessarily. As a developer, I have a thought in my brain that I wanna express it in.

[00:07:44]
Code, every tool that I put between you and accomplishing that is friction. So I have to ask myself, as the person making the tool, is that friction useful? So one of them here that might be the most controversial here is that I put the accessibility one here in my default one.

[00:08:02]
If you do something and it's not accessible, and it warns you, what you're doing is not accessible. That is friction to a developer continuing writing the code have to go fix your error rather than writing net new code. Is that worth it? I'm gonna say yes, it's worth it to make developers fix that fix their accessibility code.

[00:08:21]
But is it worth it to make sure that they have Some special schema of naming their variables. No, that's just me enforcing some dumb opinion on someone else, that's not worth it, don't do that. So that's the mantra behind this ESL config is fix errors, don't enforce the arbitrary opinions Yeah.

[00:08:45]
Dustin.
>> Will we need esent once we move to TypeScript? Will you need Esent once you move to TypeScript?
>> Yes.
>> So let's talk about the kinds of validation that we have in our code. Just very quickly, we have a format. Which is purely spacing, and what kind of quote and it's very mechanical, right?

[00:09:12]
It's like if you're writing an English like essay, do you have paragraphs in right places? Are you double spacing? Do you have tabs? You know, should this be a single double quote? It's very syntactical You have lint, which is gonna go check. Do you have like a subject predicate, right?

[00:09:32]
Like it's, it's gonna check like very simple stylistic choices in your, your English essay. Then you're gonna have TypeScript, which is gonna say, like you said, this thing, is it a noun? Does the noun fit here? Is this a verb? Does the ver fit here? So it's doing type checking to make sure that everything.

[00:09:48]
Fits in the correct place, and it is what you said it is. And then eventually we're going to have unit testing at the end, which is going to say, do all these paragraphs fit together? Do they make sense together? We're gonna check all those pieces together. So all four of those tools are checking a different facet of correctness about your code.

[00:10:10]
And therefore are all necessary. There's overlap for sure. They definitely have overlap. And we're trying to use them each in the place that they do the best, right. ESLint can cover some things in prettier. TypeScript can cover some things in ESLint. ESLint can cover some things in TypeScript.

[00:10:27]
There's the then diagrams have overlap, right. But we try and separate them out. So that Purdue only does formatting. ESLint only does stylistic checking TypeScript. Only does TypeScript checking and unit testing. Only tests do the pieces fit together, so I believe everything should work npm run lint. No errors,everything's all good.

[00:10:53]
Now we're done with the ESLint for a good long while.