Lint specification

Generally speaking, for most people, the only thing we can say about the Lint specification is esLint, which validates our code!

But how do you use a good ESLint specification in a team? With so many esLint rules, how can we easily and efficiently configure the ESLint specification belonging to our team? Those rules one by one, we have to configure a not?

Of course, there are some mature ESLint specifications in the community: the Standard specification, the Airbnb specification! (These two specifications are also provided in our VUE-CLI scaffolding)

Another aspect of the Lint specification is the validation of stylelint, which validates the style code we write for CSS, LESS, and SCSS.

So why check stylelint? There are two ways to think about it:

1, from the browser’s DOM parsing mechanism, it must first parse the DOM layout, such as width, height, position, etc., and then parse the color, etc.

For stylelint, you need to put attributes like width and height before styles like background-color.

2. From a coding point of view, we sometimes make stylistic errors. For example, we have two font-size properties in a CSS, which would not be exposed if there were no stylelint.

What are the other problems?

1, forced to change other people’s coding habits, is very inhuman! For example, if I write a CSS, how do I know which style comes first? So we need some tool support!

For example, with some editors, I can save with one click and repair the code directly based on the esLint/stylelint configuration!

For example: when submitting Git, can we use Githooks to fix and verify some code in advance?

2. People

There is a cost to adopting something new within a team, especially if team members who don’t know lint are naturally resistant to it!

First of all, we have to believe in the self-cultivation of a programmer. Everyone wants good things.

Secondly, in order to make others accept the cost lower, we can do some sharing in this aspect, collect some people’s opinions and so on.

3. Old code problems

Lint rules that access old repositories can cause code validation problems for old repositories. Generally speaking, if code does not change, no need to handle.

Once a change is made, the Lint rule will be validated when git commits, or when it is saved automatically.

So, for old code, it takes some effort to fix the problem.

eslint

For VUE, one of my specifications looks like this

.eslint.js file configuration:

module.exports = {
  root: true.env: {
    node: true
  },
  'extends': [
    'plugin:vue/essential'.'@vue/standard'].rules: {
    'no-console': process.env.NODE_ENV === 'production' ? 'error' : 'off'.'no-debugger': process.env.NODE_ENV === 'production' ? 'error' : 'off'
  },
  parserOptions: {
    parser: 'babel-eslint'}}Copy the code

In contrast, some files we do not want to use such validation rules, so we need to configure.eslintignore files

.eslintignore file configuration:

/build/
/config/
dist
test
node_modules/
static
.*
**/*.min.*
**/*.css
**/*.scss
**/*.less
**/*.sass
**/*.woff
**/*.woff2
**/*.txt
**/*.ttf
**/*.otf
**/*.eot
**/*.font
**/*.svg
**/*.png
**/*.jpg
**/*.jpeg
**/*.PNG
**/*.JPG
**/*.JPEG
**/*.md
**/*.tpl
Copy the code

stylelint

The stylelint configuration file is called stylelint.config.js

stylelint.config.js

module.exports = {
  extends: [
    'stylelint-config-standard'.// Degree style attributes for sorting formatting
    'stylelint-config-rational-order',].plugins: [
    'stylelint-order'.'stylelint-config-rational-order/plugin',].rules: {
    'at-rule-no-unknown': [true, {
      ignoreAtRules: [
        'mixin'.'extend'.'content',]}],'selector-pseudo-element-no-unknown': [true, {
      ignorePseudoElements: ['v-deep'],}],'selector-max-id': null,},// Sass files will be ignored before migration (each project configuration is different)
  ignoreFiles: [
    'src/App.vue'.'node_modules/'.'lib'.'dist'.'.git/'.'test'.'**/*.sass'.'**/*.png'.'**/*.jpg'.'**/*.jpeg'.'**/*.PNG'.'**/*.JPG'.'**/*.JPEG'.'**/*.svg'.'**/*.eot'.'**/*.svg'.'**/*.ttf'.'**/*.woff'.'**/*.woff2'.'**/*.otf'.'**/*.txt'.'**/*.js'.'**/*.json'.'**/*.font'.'**/*.md'.'**/*.min.*'.'*']};Copy the code

Stylelint how to use, in Baidu, there are many tutorials, you can go to search.

Editor support

1. Vscode editor configuration (I recommend using VScode)

Vscode is the best editor for lint rules.

There are a few plug-ins you need to install: ESLint, Stylelint, and these are mandatory (if you want to save and repair automatically)

There e are other plugins: Chinese, MarkdownLint, NPM, Sass, Sass Lint, Vetur, etc.

Json is a json file about vscode configuration. My configuration is as follows for your reference :(setting. Json in vscode, if you don’t know what it is, you can search it by yourself.

{
    "editor.fontSize": 14,
    "eslint.format.enable": true,
    "eslint.validate": ["javascript", "javascriptreact",
        {
        "language": "html",
             "autoFix": true
        },{
        "language": "vue",
             "autoFix": true
        }
    ],
    "css.validate": false,
    "less.validate": false,
    "scss.validate": false,
    "editor.codeActionsOnSave": {
        "source.fixAll": true,
        "source.fixAll.eslint": true,
        "source.fixAll.stylelint": true
    },
    "[json]": {
        "editor.defaultFormatter": "vscode.json-language-features"
    }
}
Copy the code

2. Webstorm configuration

Webstorm editor, internal performance Settings can be set for ESLint rules.

In general, WebStorm automatically reads the eslint.js configuration items in the project.

Package. json configures git hook validation

  "gitHooks": {
    "pre-commit": "lint-staged"."commit-msg": "commitlint -e $GIT_PARAMS"
  },
  "lint-staged": {
    "*.{js,jsx,vue}": [
      "eslint --fix"."stylelint --fix"."git add ."]."*.{css,less,scss}": ["stylelint --fix"."git add"]}Copy the code

The core code, which is pre-commit in gitHooks, executes Lint-staged rules, and Lint-staged rules enforce internally configured rules!

If it doesn’t work in the project, you can use ghooks, or Husky, for integration. (The reason is that gihHooks are vue scaffolding features, related to scaffolding versions)

For these, we can give you a reference project, this project is a vUE version of the warehouse template prepared by individuals: github.com/mapbar-fron…