What is Linting?

Stephen C. Johnson, a computer scientist at Bell Labs, created the first utility to inspect programming grammar for C programs in 1978. The term lint comes from the bits of dust and fiber that get trapped in wool. He notably looked at the fan intake of his terminal and noticed the dust being caught by the filter. Mr. Johnson named his program lint. Compilers are designed for speed and reducing code to machine-readable language, but humans need to have stricter rules to maintain a program's readability. His design separated coding style checks and other configurable rules that are too strict for the speed and non-type checking design compilers implemented.

Let’s explore how far linting has come in a modern progressive web application framework. We’ll take a look at Nuxt and how it handles checking code for style errors based on community-driven feedback.

The popularity of linting code was virtually immediate. One of the most difficult challenges for teams of programmers to face is writing programs that appear as one developer wrote every line. Having an automated styling guide check code as it is written helps foster better developer practices. It also avoids largely unproductive meetings about why one developer refuses to use semicolons when everyone else does.

Linting in JavaScript

Linting tools can be integrated into the build and code management systems. Many popular JavaScript frameworks and editors support linting tools out of the box, or with very little configuration. There are many linting solutions since 1978, and in the JavaScript world, two have emerged as the most popular: ESLint and JSHint.

JSHint was originally written by Douglas Crockford (author of JavaScript: The Good Parts) in 2010 and grew to add several more maintainers over the years. It’s been used to improve code quality in some of the most popular frameworks and apps including jQuery, Mozilla, Facebook, and more. JSHint uses a JSON based configuration file, as well as ‘magic comments’ in js files to handle one-off rule handling.

ESLint is a pluggable linting utility. Essentially ESLint itself is just an API, and its plugins implement the actual rules and style guides. It was originally written by Nicholas C. Zakas (authored Maintainable JavaScript) in June 2013. ESLint has surpassed JSHint in popularity, largely for its much simpler configuration and excellent plugin system. ESLint supports JSON or JavaScript configuration files, the most popular approach using a .eslintrc.js file in the top level of a project. It also supports 'magic comments'!

What is Nuxt

Nuxt is a popular framework for Vue.js-based user interfaces. It supports single page application and progressive web application modes. It also defines a well-thought-out convention for structuring front-end projects. Nuxt can be integrated into an existing project, or start with one of many hundreds of project templates.

Let’s set up a Nuxt V2 application using the community starter project. I’m assuming you’ve already installed Yarn, and if not, go ahead and do that. Then simply make a new folder and run yarn create nuxt-app .

Configuring linting in a Vue.js/Nuxt project

Once the CLI starts up you have to answer a series of questions about how you want to use Nuxt and the ecosystem around it.

A screenshot of ESLint

The most important choice in these questions is to turn on eslint and prettier . This will add the appropriate ESLint packages, create an .eslintrc.js and .prettierrc file in the root of the project. These files control what rules the project should follow. This can get quite tedious to build alone, and so many developers elect to use 'community rules' and then modify their few exclusions. In .eslintrc.js , this is found in the extends configuration. You'll notice in there that prettier is integrated with eslint very nicely.

Fixing Problems

Now that we have a basic application, let’s mess some code up and see how our configuration reacts to these grievances. Prettier has a rule to avoid semicolon usage, but I’ve gone ahead and added one here:

prettier detecting semicolon

WebStorm does the right thing here and adds a red grammar line under the semicolon, and the message explains what the linter caught when the mouse hovers. This example is very simplified. Linters can do even more! One of the most common optimizations is called a guard clause. This is when a function has received a condition that should stop its execution on the first line. Consider this:

function noguards(someTrueValue) {

if(someTrueValue === true) {

doSomeOtherStuff

} else {

doSomethingElse

}

}

This is a prime example of when a guard clause could be used instead:

function guardClaused(itsTrue) {

if (itsTrue) return doSomeOtherStuff;

return doSomethingElse()

}

Linters are excellent at determining when code could be optimized for legibility and performance.

JetBrains IDE configuration

WebStorm makes it very easy to use ESLint:

ESLint Settings in Webstorm

Click on File -> Settings. Then navigate to ‘Languages and Frameworks’ -> ‘JavaScript’ -> ‘Code Quality Tools’ -> ‘ESLint’. Turn it on and make sure your project is using the expected version of Node.

VS Code Configuration

VSCode is a little more complex to get started. To get started it will need a couple of new extensions installed:

- Prettier Now

- ESLint

- Vetur

- Vue 2 Snippets

I added this to the user settings.json file:

...

"eslint.packageManager": "yarn",

"eslint.provideLintTask": true,

"eslint.packageManager": "yarn",

"prettier.eslintIntegration": true,

"eslint.validate": [

"javascript",

"javascriptreact",

"vue"

]

...

Using Sider with Nuxt

Sider allows developers to ignore false positives actively and provide even deeper inspection of the code. One of their open source tools is called Goodcheck. Goodcheck is a great tool in a user interface project like Nuxt. You can configure the full style guide for your app in goodcheck.yml .

If the app uses ‘Register’ and a developer uses ‘Sign up’, Goodcheck can be configured to detect that and advise the required changes. Sider can run Goodcheck when a pull request is made, and notify right in line there is an issue. Goodcheck is written in Ruby, so if you use it locally you will need to have Ruby installed. Getting started is three steps: create a config file, add a rule, and then check the project.

$ goodcheck init

Wrote goodcheck.yml. ✍️ $ goodcheck check

index.html:1:Github is a nice service!: Do you want to write GitHub?

The best way to Goodcheck is in Sider where other team members can discuss and resolve any issues in a pull request. Goodcheck can import rules from a URL also, allowing teams to share a common configuration across all repositories.

Conclusion

While often errors are very annoying when constantly pointed out to developers, the benefit is as experience comes errors happens less and less. Coding style becomes muscle memory when linting tools such as eslint, prettier, and Sider are configured. Teams are happier avoiding unproductive code reviews about syntax and style. Quality of the product increases, and productivity is vastly improved when everyone on the team writes code the same way.

Finally, a copy of the project is available here.