ESLint Setup and Configuration Overview

I'm just going to start off, I'm in the terminal and I'll make a directory. I'll call it using dash yeslib. I already have it, so it's going to error out. That command is the same for either Windows, Linux, Mac OS, and then you're going to CD to the directory to change directories to that. Okay, once inside there, now we're going to create a NPM project. We're going to use NPM, the load package manager. NPM, let me increase the font. Space init, this command creates a file called package.json, so we don't have to create it manually. It asks a few questions, I usually just press enter. I don't really care, but you can always change later. Let me say yes. Okay, now you can open your text editor with this root folder. For example, visual studio code, if you have the code command, space.dot, dot meaning current directory. I already have it open, so if I press enter, it will open again. So here it is, visual studio code. I can see there's now a package.json file with all the properties with the values being the answers that were filled. It can change them here if you want. Okay, now let's install ESLint, going back to the terminal. You're going to say NPM, space install, space ESLint. Now, people usually like to add these instead of the dependencies property of package.json, they add to the dev dependencies because they like to separate packages that are only used for development versus the ones that are actually needed in production. So if you want to do that, you can add the option here between the install and the name of the package, dash dash save dash dev. Okay, now let's go back to visual studio code. And you can see we have now dev dependencies instead of dependencies. ESLint is listed here with version 8.57.0. Now let's create a file here. Let's create an index.js. And I'll just start writing stuff. Maybe I'll write a function. Hello, and I'll add some space here. Just to, you got to be intentional and make some bad code style. Just put a function with console log and then maybe I'll add a really big indentation return and I'll use maybe single quotes here. And then I'll concatenate whatever, something called an outside maybe. You can be creative just trying to have some simple code here so we can apply ESLint to and find out what the default rules are. Let's see what else can we do? Let's make a variable maybe var instead of let or const var counter negative one. I'm going to add like a without space like an equal sign right next to the R and no semicolon here. Okay, and then I'm going to add a lot of lines. Now let's just talk a little bit about ESLint. Just give it an overview. ESLint is basically, so when we write programs, every person kind of have a distinctive style, especially if you work in a large company, you got to have people coming and going, people coming and going. Somebody's going to have to look at the code, write their own solution, put it there, combine with other people's, build on top of what an other person has written and so on. And every person is kind of slightly different, especially if the language allows for a lot of customization or different ways of doing the same thing, like Ruby language, you have if statement unless, which is if not, that kind of stuff. So people might write different ways the same outcome. So some people take issue with that with a distinctive style. They want to make a code base more consistent. Instead of having people argue against each other, they establish for what are called Linter rules. So that will, it will grow through the code base and it will demand that you follow certain rules of style. So it's purely style. It's not so much as whether your solution is good or not. It's more about the reliability, how we want your code to be written a certain way, what the team thinks should be the standard way of writing just for that specific team and that code base. So yes, Lynn has many rules that you can apply. So you will look at your code and determine if you're following the standard that was set by your team or not. So you can write, you can write your own rules and change them, tweak them around to fit your heart's content. Okay, but we're going to start off with some basic standard rules that yes, Lynn already provides us when we generate the yes, Lynn RC file. Okay, so let's go to the terminal. And here I'm going to say NPS and let me glance here at the docs because they keep changing the command to create the rule getting started. You can always go to the docs getting started. There you go. So I have to say NPM init at yes, Lynn slash config. So if you use this command, it will generate the yes, Lynn RC file, according to several options that you can choose. So let's try it. Okay, so you can move the arrow with the arrow key to choose what you want to do. So if you're really loose, you just want to check syntax, oh, you want to find problems. And if you're really strict, you want a force code style. So I'm going to pick the middle ground to check syntax and find problems. Now what type of modules does your project use? So this will depend on how you're usually the client side, people like to use JavaScript modules that transpire to common JS, for example, and Node.js is mostly common JS. So in this particular example, I'm going to be using Node.js, which is JavaScript server side. So I'm going to choose common JS. Now if you use a framework like you on the client side, you know, front end development, react is very popular. So I'm going to pick that. Otherwise, I'm going to choose none of these because I'm not using them. So if you had chosen them, they would add a specific rules for that framework. Does your project use TypeScript? We're not using TypeScript today. So I'm going to say no. Now, where does your code run? Now this one, this selection is multiple choice. The first time I did this, I thought it was just single choice. It was actually multiple. So if you want to choose multiple, you have to press the space bar. So does your code run in the browser? If so, you can mark it pressing space bar here and the icon turns green for the check mark. I'm not going to have my code on the browser is just node server side. So I'm going to uncheck browser, press down arrow and then press the space key to select node. Now I can press enter to go on. Now format do you want a config file to be in? So this would be the file that we would generate it so that we can tweak the rules. So find it very easy to that the format be JavaScript. JSON is a little bit stricter, so I don't like it. So I cannot have fancy stuff JavaScript code logic there. And Yama is like JSON without the quotes usually. So I'm going to choose JavaScript.js. Okay, now successfully created .eslintrc.js. Now let's go back to Visual Studio Code to see what it looks like. Okay, created a file here and you can see it's basically an object with property and values and the standard. So this one is using if you look at extends. Extends means to like use based off a certain standard that was already written by somebody else. So they wrote these rules called yes, lead recommended. And it's the code is somewhere here node modules. If you go node modules at yes, land, you're going to find it somewhere there. If you're curious, but all the rules are defined there manually hard coded so that we don't have to do it here initially. Okay, then other settings here saying are you using common JS? Is it an old environment versus browser and all that kind of stuff. You can find more about these options in the documentation for yes, lead the website. Now, you might have noticed that my code is now highlighting stuff here. I didn't want this enabled at first. That's because I have an extension. Yes, link here, but I'm going to disable for now. Because I don't want you to see it just yet. Okay, let's go back to explore. Now this is the code and I intentionally wrote the code all kind of in a weird style without indentation here with a lot of a lot of indentation, a lot of spacing between the function name parentheses, no space after the before the operator equals using var instead of letter costs and all that stuff using semicolon versus not using semicolon. Because I'm trying to trigger some of these rules. Okay, but how do we know if we're, you know, we're doing something bad there. Now we can let me open a terminal within Visual Studio Code. You can still keep yours or use it here. So I like doing you can choose here what kind of term and I like to be covered from I mean windows so So simply what we have to do here is NPX space yes, lint. And it will check the file but you have to specify in this case seems like it doesn't check by default to detect if there are files you got to say okay what do you want to link I'm going to say index.js what files that Okay, so it linted that and you can see there's one error per line so it's saying here line one colon column five okay so if you go to line one and then you go to the right one two three four five. You know that's where the problem is the counter is assigned a value but never used. So the rule name is usually on the right hand side. It's the no dash unused bars rule. So you can click here I think usually seems like this one doesn't work, but you can always copy this rule name and go to the browser to find out what it really means if you're not sure. So you can just go to your favorite search engine and paste that name and it automatically point to the docs here and click the first result. So this is the description of the rules. If you're unsure what it means details this allow unused variables and it has several examples and you can actually tweak this rule to your own liking. If you scroll down their options and you can see this is the key. If you want to override the already default, you can go to the rules section of your ES lint RC file and you can specify the rule name as the property. And then for this specific rule, the way you change the properties is bypassing an array for the value. The first one being whether you want to error or it can also be worn or you can also deactivate this rule a lot together. Okay, so going back to visual studio code. So I already know about this rule. This just means okay you created a variable, but you're not using it. So what's the point? You know, so that's the point of that rule. Some people like their code base to not have unused variables. So what's the way of fixing it? Well, you got to use this somehow somewhere. Maybe we're going to use in the return for the hello, I can say plus counter here. I'm going to save the file and then we go to the terminal here. I'm going to run npx space ES lint space index dot js again. And there you go. There's no more error there. You notice I use npx. I don't know if you're familiar with that. That's because if I go to the node models director, there's a dot bin and there's a command yes lint here. If I were to type it manually, I have to type node modules dot slash node modules slash dot bin slash yes lint and then the file. And I don't want to type this whole thing. So instead of doing that, I just do it npx yes lint, which just means, okay, look for yes lint in this particular directory. All right. Okay, yeah, so you can continue fixing your linter issues or errors. As you see fit. The next one is, okay, errors defined but never used on line three column 10 line three. You can see the column 10 here. Usually your text editor or or IDE will show you here in my bottom kind of right. It tells me what the line is and what the column is. So hello is defined, but never used. So we got a function here that's never used. So what people usually do is they set up this yes lint command to run in their build pipeline, like continuous integration and development, like GitHub actions. And if it fails, the user is not allowed to deploy or merge those changes. So you can make like a actions file if you just get hub, a workflow that will run this command every time you try to merge something to master or try to deploy or anything. Now, if you let's say for some reason, you think this rule is kind of strict. You know, I don't like this. One thing you could do is just make it a warning instead of an error. So it never means everything's fail. You cannot proceed usually when you have continuous integration or development. But if you just want to warn, hey, you might be doing something wrong about let you pass. That's the warren. So let's change that. So we're going to go here. Yes, lint rc.js. So we scroll down to where you see the rules property here in the top level of the object. And we're going to add first. It's usually the name of the rule. This this was no dash and use bars. You can just copy that. So you can paste it here because there's dashes. I got to add quotes around it. colon and then you can define. Okay, what do you want to do? Remember the docs had what do you have to pass here? So I remember it had something like error string in an array. So if I change this to war, and let's see what happens. Now let's run yes, lint once again. Now you can see it's now a warning turn into yellow if you can see the color before the color for error is red. Now it's yellow for warning. So this means okay, something's fishy here. You might be we don't like this, but we're going to let you do it. You can deploy. Now if you don't like the rule out together, you can always disable. Let me see the docs here. Yeah, the doc says waff instead of warren. So if you don't like it, I don't like this rule at all. Just turn it off. Say off there. Now if I run a s lint again, it doesn't even complain about it. So this approach here is pretty much very common across all the rules. If you need to change any rule, just go here on the rules, add the property for the rule name and then some array. And then the first is usually whether you want it error, warning off. Yeah, let's put it back because I think that might be a good rule. So I'll make it error again. And then errors define and never use. So go to index, maybe you got to use it somehow in this file. Maybe I could do call it here and save it. Now there's no problem. Now let's add let's say we're very nitpickers. Okay, we don't like the scouting styles. Not good. I want to add a rule. For example, I don't some people like semicolons. Some people don't like it. I personally like it. So what should we do about it? How can we add there's a rule for semicolon? You can look it up in the docs. Let's try here in the yes, the RC under rules. I'm going to add a property semi. I don't need quotes because there's no dash. This rule, let's see, let's look at the docs to see what we should write here. Let's maybe the search. Make sure your version is the same as you're using in your package. Semi colon. Semi. Maybe this one. This rule enforces consistent use semicolons. Okay. Always require semicolons. The end. Okay. If you are the person that requires semicolons, you want to use always. Let's see the examples. Look, if you look here, semi. And if you write it like this, you see this is the value we should write in our rules error as the first value and the second is always. And they give an example that this incorrect code here doesn't use semicolons, for example, line 10. And this is example of correct rule. If you have the always option, meaning line 10 must have a semicolon here at the end of the line of the statement. Let's try it out. I'm going to go to Visual Studio Code. So we're going to write here error, comma, always save that. Now I'm going to go around ESLint again. Now I'm going to see, oh, some errors now, because the rule is now in place. And we must have semicolon. Okay, go to index.js. Let's see. The first one is line 116. Okay, I don't have a semicolon here, so I must add. Run it again. Okay, that one is gone. Now the second line four. Okay, I need a semicolon here. And then finally line eight, I need a semicolon here. There you go. If you run again, it's gone. Cool, but some people don't like semicolon. So what should they do? Well, just go to the rule, change it to another option. I think if we go to the docs again, let's find out how to reverse this to always force people to not have semicolon. We have omit last, never. There you go. This one, this is the example incorrect. If you have a semicolon, another correct, no semicolon. Let's try that then. If you say never here and run ESLint, now everything that we did is now deemed to be an error. And now we would have to go, okay, now they don't want semicolons. I got to delete every single line that has semicolon that is one, four, five, and eight. Save it. Run it again to get rid of the errors. You know, you're going to have some teams that enforce having it. You're going to have some teams that enforce not having it. So, you know, it's kind of annoying, but that's the way it is. Just follow it. The linter will complain it to you. Just change it. You probably might find yourself out of habit having it or not having it. And you're always going to have the linter complaining. And then you fix the problem and make the linter pass so you can go on with your life. Yes, you talked about the extension. Now the extension there are two things you can do. There's the extension that can warn you, hey, this part is kind of, you're not following the rules here and there and there. There are other, another kind of extension that will auto format everything for you on save. Yeah, so you're using the one that auto formats the bad code into good code. Yeah, you know, I usually recommend beginners to not do that at first because you must learn how to write it by yourself and get into the habit. But as you become, you know, more comfortable, I think you can use it and rely on that. You know, some people might get, you know, angry because, ah, this is complaining because I did this and that. So just make peace, auto format, save and go on. Anyway, let's talk about the extension loud out of your mention it. Go here and you can search for extensions. I'm using Visual Studio Code, but whatever ID you're using, probably will have a similar thing extension plug in whatever it is. You can look for a yes lint and Visual Studio Code has the one provided by Microsoft and this is the one I recommend. You can click to install. I already have it, but I disabled it. So I'm going to enable it and I'm going to close it. I think I have to reload. So if I control shift B reload window. I have to make the errors, right? So if I press type a semicolon there, you see it's going to start complaining. Hey, extra semicolon. And it tells you what the rule name is. And what's nice, you can click this and it will open an external website that goes to the docs. But that's very convenient. Yeah, you can see under problems if you open usually control back tick. To open this kind of thing. There's a problems tab that you can see if you want to evaluate if you have any yes lint problems here and click click here and it goes to the exactly to where it is. So we can fix it. Okay, I go click here, remove it. Click there, remove it. So that's very convenient. Let me see what he wrote. Yeah, beginner do have bad inhibition, no semicolons, etc. Yeah, that's why I don't recommend doing all this of auto format of save when you're starting out. But as you get used to it, you can start using it. Yeah, so yes, lint is pretty much that there's no secret to it. Usually teams will meet together to determine what rules are more interested in. Maybe if you come as a new teammate, you might not like certain rules and probably will won't be able to change them but just follow them and make peace. It's not worth fighting over that. Yes, there are more advanced lint rules that just that not only touch upon the style that they look for certain things you can customize to your use case. Yeah, that precautions is very common. For example, a company has their own certain library. For example, their design system and they're always constantly releasing new versions, but they're breaking changes. So what they do is they write a linter that will tag all those breaking changes. And as the developers who are relying on that design system are using it, they will see, oh, this is now deprecated. They will see a message there every time they run their build runs yes lint or within their IDE if they have the extension to let them know of any problems. So it's very convenient for identify the application so you can change your code promptly. I think going from here, you can customize your own rules. You know, I didn't touch upon this indentation. That's probably bad. There's probably an indentation rule and if I would guess would be called a dense. Let's go here. I think it's indent. Indent yes lint if you look for that. Yeah, it's indent rule. You can say indent. L'Ore. And probably you got to say error and then maybe two to specify how many spaces you want. Yeah, there you go. It even cares about my yes lint rc file and it's tagging it. If I go back to index now it says okay, this is a problem. I want two spaces of indentation but found 24 you can fix it manually. But now my ID Visual Studio Code does have a quick fix here. I can click and it fixes the problem for me. So that's convenient if you're like, I'm tired. But again, I don't recommend for beginners doing that. This should do by hand. Anyway, this one you can go here quick fix would be adding two spaces to the left or can click here. Control dots it seems. Enter, there you go. It's fixed. Save it. This is my yes lint file. I don't want to lint that but it's here. That's probably an option to ignore it. There's probably a rule to add a space before the equals. I don't know specifically what rule. That would be nice to find out. Another one is to not have either have one space here or no space at all between the function name and parentheses. There's also rules that prevent you from doing concatenation like this and prefer you to do a back tick interpolation and so on. It's very nitpicky. Like you said, there's probably an ignore option or file that you can choose. But typically when you run yes lint you run a specific file that you have to say yes lint space, either the folder pattern or files. Yeah, so that's it.