Code Linting (Lint) is an important way to ensure the consistency of Code specifications. Do you have Lintin your workflow? Did you enjoy it? You promoted Lint on your team, but no one bought it? Why on earth?

What is Lint?

Before exploring how to do this, it’s important to give Lint a clear, precise definition, as wikipedia defines it:

In computer programming, lint is a Unix utility that flags some suspicious and non-portable constructs (likely to be bugs) in C language source code; generically, lint or a linter is any tool that flags suspicious usage in software written in any computer language. The term lint-like behavior is sometimes applied to the process of flagging suspicious language usage. Lint-like tools generally perform static analysis of source code.

Simply put, Lint is a tool that does static analysis of code and tries to find potential problems. In practice, we also use Lint to refer to the process of using tools.

Why Lint?

What are the benefits of using Lint? In my opinion, there are at least three points as follows:

  • Fewer bugs. A Cambridge University study found that soft bugs cost the world an estimated $312 billion a year.
  • Higher development efficiency, engineers spend an average of 50% of their working time locating and resolving bugs, some of which are obvious low-level bugs, while Lint can easily find low-level, obvious bugs;
  • Higher readability. The number one factor in code readability is “surface writing”. Code that looks messy on the surface is often harder to read.

It’s safe to say that if you don’t do Lint, you’re wasting your time and your company’s resources. So now that Lint is supposed to work fine, right? How do you do that?

Lint after submission: Too long feedback chain?

There are a number of front-end tools that can be used in various languages: ESLint, Standard, SCSSLint, JSONLint, HTMLHint, and so on. GitHub’s list of Lint tools is also a good reference.

Many students choose to do Lint during the continuous integration phase, for example using remote Git Hooks. But in practice, the feedback chain is usually as follows:

Code submit --> Find problem (remote) --> Fix problem --> Resubmit --> Pass check (remote)Copy the code

The whole process can be a waste of your time, after all, CI processes are usually not just doing Lint, and if you’re the kind of engineer who doesn’t know where your time goes every day, you might want to rethink your workflow or your team’s. And, believe me, you’re not alone.

Have you ever had the experience of writing code after several days of hard work, passing all kinds of checks, and finally being rejected by CI because you lost a comma in your code?

From the number of submissions on GitHub for various fixes Lint, it’s easy to see how much time engineers are wasting fixing Lint issues, such as searching for “fix Lint “, up to 45W submissions:

Search for “fix indent” and you’ll get 226W submissions. Isn’t that shocking?

The disadvantages of only doing Lint in CI streams are also obvious:

  • Lint’s feedback chain throughout the development workflow is too long, wasting time, attention and resources, and most deadly;
  • CI process construction costs are high, even if Travis CI service, the steps are still cumbersome;

How can we improve?

Lint: Error messages not relevant before submission?

To shorten Lint’s feedback chain, moving Lint locally is the most effective way. The common practice is to use husky or pre-commit to do Lint before committing locally.

Here’s how to use Husky:

First, install dependencies:

npm install -D huskyCopy the codeyarn add --dev huskyCopy the code

Then modify package.json to add configuration:


     

      {
      


     

     

        "scripts": {
     

     

          "precommit": "eslint src/**/*.js"
     

     

        }
     

     

      }
     
Copy the code

Finally try Git commit and you’ll soon receive feedback:

git commit -m "Keep calm and commit"Copy the code

But those of you who work on legacy repositories can quickly run into new problems, and you may be faced with thousands of Lint errors that need to be fixed in the early days of Lint. Some students may be familiar with the following figure: only file A has been changed, but there are also A lot of errors in files B, C and D.

Formatting the entire warehouse is an option, but it actually takes a lot of courage. Most people want to implement new tools in a project incrementally, rather than in a do-over fashion, because business system stability is more important. By simply moving Lint to local, the feedback chain is shortened, but the tool still provides too much irrelevant information for each change, which goes against the fast-paced pace of the Internet.

How do you break it?

Lint only changed: 66666

All of the above pain points would be resolved if you moved Lint to the local location and only checked the files that you changed with each commit. Feedly engineer Andrey Okonetchnikov based this idea on Lint-passage, which is a concept from Git called “to commit” sections, using Git commit-a, Or git add and then Git commit, your changes will go through the commit zone.

Lint-passage can be used like this:

First, install dependencies:

npm install -D lint-stagedCopy the codeyarn add --dev lint-stagedCopy the code

Then, modify the package.json configuration:


     

      {
     

     

        "scripts": {
     

     

          "precommit": "lint-staged"
     

     

        },
     

     

        "lint-staged": {
     

     

          "src/**/*.js": "eslint"
     

     

        }
     

     

      }
     
Copy the code

Finally, try the effect of submission:

Lint-staged episodes actually give you more freedom in how your code will behave before submission, such as automatically fixing errors using the following configuration:


     

      {
     

     

        "scripts": {
     

     

          "precommit": "lint-staged"
     

     

        },
     

     

        "lint-staged": {
     

     

          "src/**/*.js": ["eslint --fix", "git add"]
     

     

        }
     

     

      }
     
Copy the code

Or use the following configuration to automatically format the code (use caution) :


     

      {
     

     

        "scripts": {
     

     

          "precommit": "lint-staged"
     

     

        },
     

     

        "lint-staged": {
     

     

          "src/**/*.js": ["prettier --write", "git add"]
     

     

        }
     

     

      }
     
Copy the code

In addition, Lint-staged and Prettier are already integrated into creation-React-app. Isn’t it time to polish your Lint workflow?

conclusion

Some people say front-end siege lions are the strangest animals in the world, prettier when they submit code, but uglify when they deploy it doesn’t even recognize her mother, the truth is, we wouldn’t need Uglify if the code we write was ugly. Hopefully, you’ve read this to polish Lint workflow to the limit, spend more time on solving real problems, and become a truly effective engineer.

One More Thing

The author of this article is Wang Shijun. For commercial reprint, please contact the author for authorization. For non-commercial reprint, please indicate the source. If you found this article helpful, please give it a thumbs up! If you have any questions about the content of this article, please leave a comment. Want to know what I’ll write next? Please subscribe to my nuggets column or Zhihu column: Front End Weekly: Keeping you Up to date on the Front End.