preface

ESLint as a plug-in javascript code detection tool, for our daily development protection, not to say more details check the website.

The problem

There was an old project developed five years ago, and it happened to come to our side for maintenance. Zepto stroked up the project, the individual files were huge, and only gulp+ ‘s ancient packaging tool did the simple packaging. But the serious problem is that now es6 writing is used, there are always some places in the old project will be ignored directly using ES6 syntax. This code is not translated by Babel, however, in the current situation, most browsers can run, only some domestic mobile phones represented by Blue green factory do not support. The test did not cover all models. Cause problems after online. It was against this background that discussions were held about how to deal with such old projects.

The solution

The solution is also very simple, nothing more than the following three

The program

If you have enough time and are iterating a lot, migration is preferred, otherwise zepto will write files that are too large and difficult to maintain. Pass this one based on the current situation.

babel

Since it is not transferred to the existence of the problem, the transfer is over.

Syntax checking

Before committing, check the ES6 syntax to make sure it doesn’t exist before allowing the commit. On balance, the syntax check was chosen, along with a review of esLint usage.

The installation

// Can be installed globally
npm i -g eslint
// Or the project is installed locally
npm i -D eslint
Copy the code

After installation, initialize (of course you can reuse existing.eslintrc.js) :

eslint --init
// Non-global installation
./node_modules/.bin/eslint --init
// Select the initialization type depending on the specific purpose
 How would you like to configure ESLint? (Use arrow keys)
  Use a popular style guide  // Existing popular norms, which are preferred
❯ Answer questions about your style // Answer the questions to customize
  Inspect your JavaScript file(s) // Check the existing js file to generate
Copy the code

I chose 3, because I thought it would be nice to generate it directly. The order follows:

Which file(s), path(s), or glob(s) should be examined? ./js // The directory to be detected
? What format do you want your config file to be in? JavaScript // The configuration file is in eslintrc.js format
? Which version of ECMAScript do you use? ES5 // ES5 currently in use
? Where will your code run? Browser / / the browser
? Do you use CommonJS? Yes / / CommonJS specification
? Do you use JSX? No // Do you use JSX
Copy the code

After that, our configuration file is generated:

// Too long, just focus on what we care about
    // The environment section is self-selected
    "env": {
        "browser": true."commonjs": true
    },
    // Extending configuration ESLint :recommended is a core rule
    "extends": "eslint:recommended".// Supports the ECMAScript specification, also 5 by default
    "parserOptions": {
        "ecmaVersion": 5
    },
    // Check the rules
    "rules": {
        / / * * *
    }
Copy the code

The configuration file is generated, so go ahead. Direct execution to see:

// Check the files under the folder
./node_modules/.bin/eslint ./js
Copy the code

And then reported 1020 errors… After all, it was an old project, and it was unrealistic to conform to the specifications. But it doesn’t seem like our goal is to go to all this trouble and just disable ES6. Eslint provides this option: just drop false. Actually, we don’t need rules, because it’s an old project and we don’t want to do this restriction. So I changed the configuration file to look like this.

    "env": {
        "es6":false
    },
    "parserOptions": {
        "ecmaVersion": 5
    },
    "rules": {}Copy the code

This looks good, I only found the es6 part of the fileThere was a problem, however, with the huge old project having too many files. It’s a bit wasteful to have to check all the files in the JS folder every time. After all, we have such a premise, this time unchanged is considered to meet the requirements (after all, problems have been fixed), we should only pay attention to this part of the change. Think so many people, have made the following tools.

lint-staged

It makes more sense to check before commit so that the error code is not committed to the repository. Checking all files is slow and some of the results are inconsequential, you only care about the content of the change. This is where Lint-staged things come in. Installation and use:

// Remember that Lint-staged and Husky must be fully installed
npm install --D lint-staged husky
Copy the code

Husky can prevent bad commit, push and more. Git hooks. It can be used like this:

{
  // Manually hook yourself
  "scripts": {
   "precommit": "npm test"
  },
  / / use husky
 "husky": {
   "hooks": {
     "pre-commit": "npm test"}}}Copy the code

Just so you know, don’t forget to have this tool installed, or you’ll find that lint-staged configuration doesn’t work (I don’t want to say how I knew this…). Go to github homepage and it’s easy to use, just add a configuration in our package

"scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "*.js": [
      "eslint"."git add"]}Copy the code

Thus, only the JS files in this commit are checked.

So with Lint-staged, we can encode our package.json

"scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "*.js": [
      "eslint"."git add"]}Copy the code

The end of the

At this point, the old project ban ES6 is complete. Under simple tests, the coverage is ok, at least with the usual methods. Just use ESLint + Lint-staged (antinized passage) to briefly glance over and consolidate the original unfamiliar areas and make a record for yourself. I hope it can help students in need.