1.2 Modern JavaScript Linting With ESLint

Hi folks, ESLint is designed to be used primarily from the command line, and can be installed via MPN. It needs to run on NodeJS, so if you don't have that installed already, head on over to NodeJS.org and follow the installation instructions for your platform. Let's make a start by creating a project folder. I'm going to put mine in my user folder and I'm gonna call it eslint-course. And in here we can add a js folder. I've got a pre-written JavaScript file with a bunch of lint errors in it on my desktop and I'm just gonna drop that in to the JS folder that we just created. Let's just open the new folder. We can initialize MPM, so we can install ESlint to the project. We can do that with the MPM init command, and I'm just gonna accept all of the defaults by hitting Enter for each question. We can always come back and edit this later if we need to. Okay now that that is done we can install ESLint locally to the projects that we've just initialized. Before we can use ESLint, we need to add some configuration. The quickest way to get up and running is by using the ESLint init command on the command line. But because we didn't install ESLint globally, we can't run the command ourselves. We can get MPM to run it for us, though. Let's just open up the project in an editor now. We can MPM to run the ESLint command for us. Let's open up the package.json file, and in here we can see there is a scripts object. And inside that there is a test command, which at present just outputs a message to say that no test is specified. Let's change that to run the eslint--init command for us instead. So now we can run this command with the MPM test command from the command line. Just like with NPM init, the eslint init command will start up a series of prompts which will ask us how we want to use eslint. For the first question, let's go for option two. Use a popular style guide. We can now choose between several popular style guides, and let's just go for the Air BnB one. The next question asks if we're using React I'm gonna say no here because I'm usually more an Angular guy personally. And the next question asks which formats we would like our configuration file to be in. JavaScript is the prefered format so let's go with that. This will then install some plugins, generate the configuration file for us at the root of our project, and the process should be complete. We should now be able to run ESLint on the test file that I added to the JS folder. We just need to update the test scripts back in the package.json file. So, instead of running the init command, we want to run ESLint on any JavaScript file in any subdirectory within the JS folder. So let's just try running eslint now on the JS folder. We do that once again with the mpm test command, which we've just updated. Let's just open up the test file that has generated all these errors, And as you can see, this tiny, tiny file contains 41 various lint issues. Some of these errors we probably want to fix. The use of window and document generate errors. So the fourth arrow down there, it says window is not defined, when we're developing for browsers we're usually going to want to be able to use these globals. So we can fix these errors and other similar errors very easily by specifying an environment that we're using. And we can do that in a number of ways. As we have a configuration file, let's use that. So the configuration file is the .eslnrc.js file let's open that up quickly. And we can add environment using the key mth, so let's add that at the bottom after the plugins. So the mth key should hold a configuration objects, and we can add the various environments in there. So the one that we want to add this time is called browser, and we just set that to true. The reason way M takes an object is because we can specify multiple environments, if we need to. So, for example, we probably also be using Jasmine or one of the other test related environments. So now, let's run MPN test again, and now, we're down to 38 errors. Using environments is great for quickly allowing a bunch of known globals that we will be accessing in our code. If the globals we want to use don't have a predefined environment in ESLint, we can easily specify additional globals using a globals key in the configuration file, which takes the same format as the nth key. Okay, so now let's say we want to disable one of the areas. Let's say we're not interested in the line breaks errors because we're working on Windows, and everyone else is working on Windows on this project, and the line endings don't matter. We can't use an environment for this, so we'll need to configure the error itself. This time we need to use a rules key in the configuration file. Select the nth key, the value for rules should also be an object. And inside this object we can specify which rules should have which setting. There're various settings. If we want to disable the rule completely, we can add a zero. If we want to change the arrow to a warning then we can set it to 1. Or if we want to specify that a rule should be an error, we can set it to 2. So in this case, we want to disable the line break style rule. So we can do that by setting it to 0. So let's go back to the command line now. And let's run the npm test again. So now we're down to just 29 problems. I should mention at this point that only errors will generate an exit code of one. And an exit code of one will generally fail a build ESLint were included as part of a build process. So as well as checking for errors, we can also have ESLint fix some of the errors for us automatically. This is done using the fix flag, to add this we need to go back to the package.json file and update the command that MPM is running for us. And we just need to add the fix flag at the end, and that is --fix. So now let's try running the npm test command once again. So this time it's fixed many of the problems that it has encountered and is left only six problems the it can't fix. And you can see the file itself has been updated, there are now lots more white spaces than they were previously and some semi colon have been added for us. ESLint has been written to be modular and extendable with new rules, plugins, environments and preprocessors. It's tagline on the ESLint website is that it's the plugable lint utility we don't have time today to look at creating a plugin and it's entirety. But let's look at how we would implement a custom rule, if we needed to. Let's say that we have a requirement that all of our JavaScript files should be wrapped in an iffy. By default, ESLint does not have a rule to enforce this. Although, it does have a couple of rules related to iffys, there are none that match this exact requirement. So we'd have to create it ourselves. So first of all, we'll need to create a new file inside the node modules ESLint Lib Rules Directory. And the name of the file should match the name of the rule that we want to enforce. So let's create a new JavaScript file in this folder and call it Require-Iffy. So we want this code to run in strict mode, so we'll start our by adding the use strict iterative, and as this file will be a node module it should export an object using module.exports. We need to add particular keys to the exported object in order to configure the rule. First we need to add a meta object that will provide some metadata for our new rule. Inside this object, we should add some documentation for the rule using the docs object. We can add a description, specify a category and configure whether or not the rule is recommended. So the description will be shown when the error is reported in the command line. It's a stylistic issue, so that's the category that we're going to add our rule to. And we don't need it to be recommended, so we set that to false. There are a couple of other things we can add to the meta object, such as specifying whether the rule can be fixed when using ESLint in fix mode and a schema for the supported options. But we don't need to use these in this case, so I'm going to skip over those parts. So next we need to provide a create function, and we can add that directly after the meta object. This function will return an object. And the function will be automatically passed a context object. And this contains a number of useful methods for working with rules. We'll cover these in more detail as and when we need to use them. The create function should also return in object and we can use this objects to add methods the ESLint will invoke when visiting nodes in the abstract syntax tree that it generates when browsing the firewalls and checking them for Lint errors. One method that we need to use for our rule is called only cold path starts. So let's add this first. So the value of this property is a function. And this function will automatically be passed a code path parameter and the node in the AST being visited. Inside this method we can then test whether an iffy has been used. The node object passed through the method may contain an array of all of the tokens in the file that is currently being passed. A token is basically any symbol, identifier, or keyword in the JavaScript language. So in this conditional we're checking in to see if this has a node property and if it does have a tokens array, we're checking that the first token is an opening parenthesis. Because if we're using an iffy the very first character should be an opening parenthesis. And we can also check that the second token in the token's array has a value of function. So if neither of these conditions are true we know that an iffy has not been used. And in this case, we can call a function called report. We'll add this function in just a moment. And we're going to pass the node that was passed to our on-code path start callback to this report function. So don't forget, the function that we set for on code path starts will get invoked by ESLint as it is checking the files. So let's add the rapport function next. We need to do this before the return statement, And we know that this function is gonna receive a node as an argument. The context objects that get passed to this create function contains a method called report and that method is used to generate the report in the command line output generated by ESLint. So we're going to invoke that method on the context object inside our own report function. We need to pass a configuration object to the report method. We need to set a node property to say which node we want to generate the report for and that's the node that gets passed to the report function. So that's our report function. And we also need to specify a message. So, we're specifying a message that is contained within an error object. And, we' re going to make that a constant, and that's why it's all in uppercase. So, next let's define the constant. And, this is gonna be a regular object literal, and it will have a message property. So this is the message that we want to appear in the command line output if a file that is being linted is not wrapped in an iffy, so let's put something to that effect. So we should now have enough to check for our rule when running ESLint. We just need to configure the rule in the .eslintrc configuration file. And we can do that inside the rules objects and we just use the name of the file as the name of the rule. And we want this to be an error this time, so we give that the value 2. We could set it to be a warning by giving it the value 1. But in this case, we will go with the full error and set it to 2. So let's try running the MPM test command once again. So the test file at the moment is wrapped in an iffy and we don't see the message so that's good so far. So let's go back now and get rid of the iffy from our test file, And then let's go back and lint our file one more time. And we can see it right at the top there. All files should be wrapped in a iffy, perfect. There is no way that this custom rule could be part of the official suit ESLint rules, because we haven't added any unit tests for our rule. But this is enough for us just to use the rule locally on own machine. And it would be easy to share this with other people working on the project if necessary. Creating an official rule with tests however is definitely the recommended option. So in this course we saw how to use ESLint to lint our code. We saw how to set up ESLint using the eslint init command to walk us through setting up a configuration file, and installing any plugins we want to use. We also saw how to set up an environment of predefined globals and how to enable or disable any of the built-in rules. We also saw how we can configure whether particular rules should be full on errors or just warnings. Lastly, we saw how to easily extend ESLint with our very own custom rule. My name is Dan Wellman from all of us here at Tuts+ thanks for watching.