ESLint

[00:00:00]
>> We do want to get involved with some other JavaScripty friendly tooling that can help us make sure that the code we are about to push to the interwebs for all to maybe see or not if we haven't done right, Anjana, [LAUGH] is one very handy type of tool, is called a linter.

[00:00:22]
Has anybody worked with linters before? Yeah, okay, so folks have maybe heard of this, eslint. And again, that's es ECMAScript. [LAUGH] So the eslint is a super popular one, there are lots of others. But essentially, the idea here is that this linter is a program that's gonna look at our code base and do the jargon term.

[00:00:43]
And be like statically analyze all the files that we have and the text in those files. And make sure that we don't have any obvious, glaring errors that are defined by some rules that we can customize for a given project. But we can also use some kind of default best practice rules that are baked in already out of the box.

[00:01:06]
And that's what we're gonna be doing today. So these are things like, for example, if you declare a variable, but you never use it, you never refer to it, you don't need that. It might not be a bug, but it's probably something that you don't really want just hanging around your code base.

[00:01:24]
And so linters can catch that type of thing for you. They can also catch reference errors and things like that before you actually run the code. Before you even push the code, you can catch some degree of issues. Not all of them, obviously, because [LAUGH] then we wouldn't need to be doing this.

[00:01:43]
[LAUGH] But the idea is that we will be installing eslint in our project repository. So what we can do is together, we can do this in whatever your selfie cam project was. If you called it selfie cam like I did, or if you called it something else. But the Vite project that we started earlier, we can go into that directory and run from within that directory this command npm init @eslint/config.

[00:02:25]
And I will move over to a window so we can all do this together. What did I call it? awesome-vite-starter was what mine was called because I already had, I'll talk about that later, I already had a selfie cam. [LAUGH] So can folks see this? Okay, so now pretend that this is what you called your project.

[00:02:49]
So if we run, whoo, [LAUGH] always typing it in the wrong window, it's like my whole vibe. Okay, whoo, fun tabs. If we run npm init @eslint/config, we're gonna get a handy dandy little wizard similar to our Vite project bootstrapper that's gonna walk us through some choices. And what this is going to do is set up eslint as a development dependency of our project.

[00:03:21]
And set up some configuration for eslint so it knows what type of project this is, what kind of things, what kind of code I'm gonna be working with, etc. Now, eslint comes with what are called rules and sets of rules. So for example, no unused vars or no unused variable declarations that you never refer to again.

[00:03:47]
And these are kind of grouped into different sets so that we can have some sets that are related to syntax problems, syntax errors. Then we can have, for example, a const equals semicolon, not JavaScript. JavaScript's just immediately gonna have a problem with that, so eslint can catch that for us.

[00:04:08]
That's a syntax problem. Then it can also find those other problems that aren't illegal JavaScript, things like the unused variables. And there also is the option to enforce some formatting with eslint, but we're not gonna use it for that, we're gonna use something else. And so right now, we're gonna stick with this middle version, the check syntax and find problems.

[00:04:33]
And what type of modules does our project use?
>> JavaScript.
>> Exactly, yes, this is referring to ECMAScript modules, but the import export modules, not the require module exports, CommonJS modules that were the older solution. So we're gonna choose that one, fabulous. Which framework do we use? None of those, vanilla all the way.

[00:04:56]
Are we on TypeScript? No, not at the moment. And where does our code run?
>> Browser.
>> For this project, we're not developing a command line tool or something, some other library that we expect people to install in their node backends. We're writing front-end code, so we want Browser.

[00:05:17]
And for this one, we're gonna choose JSON. I'm just gonna dictate that. [LAUGH] So we'll choose JSON for the config file. Okay, so now, Did I say I'm using, I said I'm using TypeScript, oops. All right, well, hopefully, you did not say that you are using TypeScript. If I'm like, no, I didn't want any of this, what I just did is press Ctrl+C and it aborted.

[00:05:46]
So I can run through it again and type in the correct values. So I want syntax and problems. We're using ES modules, we're not using a framework. We are not using TypeScript. We are in the browser and we want JSON. Okay, so now it's gonna say something like, all right, you have asked me to set this up and I am going to need to install a dependency of ESLint.

[00:06:11]
Well, that makes sense cuz this is what we're asking ESLint to do. So I accept, I consent, thank you for asking me. Okay, and which package manager are we using?
>> npm.
>> npm today. And then there it goes. So now it is running behind the scenes, a little install, and it says it also successfully created an eslintrc.json file in my project.

[00:06:37]
So I'm just gonna close this, Don't Save. So if I go into my project here, I'll see I have a new .eslintrc.json file, which is, again, in the JavaScript npm package world, we're gonna have lots of different tools that have their own configs. We're gonna talk about Vite has its own config files, too.

[00:07:02]
So we'll get used to seeing lots of JSON files with [LAUGH] settings and things. And so right here, we just have some of the default, kind of out-of-the-box rules, are this eslint recommended? And unless your project has any specific reason to use other things, that should be fine.

[00:07:21]
That's all we're gonna do today. But if you have some specific rules you want to include, maybe some custom rules that your company has, for example, or anything else, you can also add into this rules object here. You can specify which other rules you want to use. And those will be added with, as you might guess, from this extends keyword, those will be added in addition to whatever else you've kind of pulled in from that extent.

[00:07:52]
Okay, so now, [LAUGH] and I don't need to say that. We wanna take a look at our package.json. And notice that we have a new friend, a new dependency in our dev dependencies, because the linter is something that we run as developers before we send the code to the interwebs, ideally.

[00:08:15]
[LAUGH] And not something that our users are gonna be running in the browser. This is a dev time helper. So now we have an eslint dependency. Okay, now, how do we use this thing? So there is a fun little command that comes with npm called npx. And what that does, it essentially allows you to run a dependency of your project.

[00:08:47]
Yeah, just as if you're running it at the command line and you have it globally installed, let's say. So what I could do is npx eslint, and maybe ask it for eslint, what's your deal? Okay, well, at least it exists, so that's nice, it tells me some things.

[00:09:05]
Look, a bajillion options, almost like every CLI [LAUGH] tool ever. So we're not gonna worry too much about all of this, but essentially, about all of the configuration and everything. But the idea is that by default, eslint, when we run it, is gonna look for that .eslintrc.json. And we're gonna maybe give it some optional options, but we're gonna tell it where we want it to look at our code.

[00:09:32]
And so in this case, we probably wanted to look at everything. So what we can do is run npx eslint [LAUGH] and then dot for the current directory, and it will go through. And okay, well, there was a small delay and nothing really happened, but that might be because nothing is wrong.

[00:09:55]
So let's make something wrong and see if it can catch it. All right, so for example, that shouldn't fly, I just put two random backwards thingies. VS Code is already like, that's not, you're not, nope, and there's a little Easter egg there. But so now, if I run es, hopefully, this is gonna catch it.

[00:10:16]
Indeed, it's like I have a parsing error in camera.js. You can't start a JavaScript file with a closed square bracket. Anjana, what are you doing? Don't do anything further, just go fix that. So that's good to know, right? This is actually gonna be catching not just the syntax errors, but also stuff, like I said, const.

[00:10:40]
If I have a useless variable, and you can see VS Code is already telling me something's wrong, which is because there's an ESLint integration, which we're gonna talk about soon. There's ESLint integrations for code. But so yeah, so if I run it again, it's gonna tell me, yeah, in that file camera.js, useless is assigned a value but never used.

[00:11:04]
And that's the rule, no unused vars. As we get into more and more complex projects and as we are, something is on fire and we have to fix it really quickly, we really appreciate eslint doing all this for us. And we probably wanna go bake this into our package script so that we don't have to keep going and running npx eslint., right?

[00:11:31]
So after I fix this, [LAUGH] what I can do is go into my package.json. And these scripts in this little thing here, these were put in by Vite, but I can put in whatever scripts I want here. And they will be run within the kind of dependency access.

[00:11:50]
So I don't need that npx the same way I do when I'm running it from the command line. Because if we're running these scripts, we're running them with npm run. And so it already knows where we are, and that we want to run the dependency of our project called Vite, for example.

[00:12:05]
So what I can do, and what you'll often see, is add a lint script with whatever the lint command is. If we have very complex flags and things, options that we want to be passing into the eslint command, we can bake them all in there so we don't have to type them every time.

[00:12:23]
So I can save this. And now, just like I could run npm run build, I'm able to run npm run lint. And actually, let me unfix this just so we can make sure it's still catching. And it does the same thing, but within our project. So again, it's catching problems, it's catching syntax errors, it's doing all kinds of helpful stuff.

[00:12:53]
And so then what you can also do, and what you'll see in larger complex projects, is you'll then have scripts that kind of layer these different scripts together. So for example, I could have something like, before I build, for example, I could do an npm run lint, and then the and is like, if that succeeds, then go on with the build.

[00:13:19]
So if the linter fails, let me unfix, I should not even get to wasting my computer's resources on running the build and wasting my time on like if there's a very a lot of optimizations happening. So let's see what happens now when I run npm run build. It's like whoa, whoa, whoa, whoa, whoa, whoa, whoa, first of all, you have to pass lint and you didn't.

[00:13:48]
And this is telling me when I run, sorry. Okay, when I run build, npm is looking at, okay, what does your build script say to do? It says to do npm run lint and and vite build. So first, I'm gonna do npm run lint, what does that say to do?

[00:14:13]
That says to do eslint., so check the files in this directory. And that did not succeed, so I'm not gonna do it. Okay, so but now if I fix the problem and I try this again, hopefully, we got through the eslint and we got to the vite build step.

[00:14:38]
So this is how we can start to bake in any other checks and balances that we need. As projects get bigger and as teams are collaborating across time zones and whatnot, it's very helpful to all be on the same page about this needs to pass the linter before it can go to the build process.

[00:15:00]
And with things like an eslint config file, and there are a few other ways to do the config as you might have gathered from the prompts. This way, everybody that's using this project, everybody that's developing this project is gonna be using the same set of rules. So that's fun, cuz otherwise, chaos might ensue.

[00:15:23]
So if you want chaos, don't do this.