Front end workflow

Time:2020-11-27

background

When many people do a project, they always need to unify the style through the way of document agreement because the code style is not unified.

For example, the file name method, some people’s initials are uppercase, some people’s initials are lowercase. In JS, TS, Vue, there are different styles. In view of this situation, we set up a contract document to specify how to name the folder. However, this kind of disadvantage is that it can not be solved from the root, that is, new colleagues may not know the rule, and then create a new file name that is not agreed.

In addition to the file name, the submission specifications are also quite different. Some people do not add type when they commit. We also have a contract document.

Slowly, the file directory has more than one doc
Front end workflow
Documentation is good, but it doesn’t limit the problem at the root. Therefore, the current front-end projects lead to the concept of workflow, and there are many auxiliary tools for customizing workflow.

Workflow overview

Multi person project, always need to specify some specifications, in order to make the code style as uniform as possible. We need to use the following tools:

eslint & prettier

Here’s a better onearticleI will not discuss how to configure it here.

Commitlint code submission specification

Commitlint is used to help teams comply with the submission specification. More information can be foundOfficial website

install

npm install --save-dev @commitlint/config-conventional @commitlint/cli

format

[type]: [subject]

  1. Type is the following field

    • Feature: new feature
    • Fix: fixing bugs
    • Documents: documentation
    • Style: format (changes that do not affect code execution)
    • Refactor: refactoring (i.e. it’s not a new feature, it’s not a code change that modifies bugs)
    • Test: add test
    • Choose: changes in the construction process or AIDS
    • UPD: update function module
    • Workflow: work flow
  2. Subject is the description content, such as
    Fix device log color value conversion
  3. Complete description, ⚠️ Notice the space after the colon, for example

    Git commit - M 'fix: fix device log color value conversion problem'
    Git commit - M 'choose: modify commitlint configuration file'

commitlint.config.js

Commitlint supports verification in the form of terminal input instructions and configuration files.
The specific contents of the configuration file are as follows:

Rules field, which is composed of name and configuration array. The configuration array includes:

  • Level[0,1,2]: 0 means that the rule is disabled, 1 is treated as a warning, and 2 throws an exception
  • Applicable always|never: apply rules
  • Value: change the value applied by the rule

Configuration array can be: array, return array function, return array promise.

module.exports = {
    extends: ['@commitlint/config-conventional'],
    rules: {
        'type-enum': [
            2,
            'always',
            ['upd', 'feat', 'fix', 'refactor', 'docs', 'chore', 'style', 'revert'],
        ],
        'type-case': [0],
        'type-empty': [0],
        'scope-empty': [0],
        'scope-case': [0],
        'subject-full-stop': [0, 'never'],
        'subject-case': [0, 'never'],
        'header-max-length': [0, 'always', 72],
    },
};

Configure git hook

Githook is actually your callback during git operation. Here, we only care about a git hook, which is pre commit, the callback before submission.

After the commitlint configuration, we have configured the submission specification, but we have a problem: when should we verify the submitted specification.

From commitlint’s official website, we know that we need to install husky, which can implement githook through simple configuration.

husky & yorkie

Help us to be able to package.json Configure git hook

Husky is here package.json The configuration is as follows

"husky": {
    "hooks": {
      'commit-msg': 'commitlint -E HUSKY_GIT_PARAMS', 
    }
  }

If we’re going through Vue’s scaffolding(vue-cli)The project is actually used internallyyorkieYorkie is you Yuxi who made a small change after fork husky
So at this time package.json You can configure it like this

"gitHooks": {
        "commit-msg": "commitlint -e $GIT_PARAMS"
 },

Note that the two configurations pass different parameters to – E. one is husky_ GIT_ Params, one is GIT_ PARAMS。
Husky used to be a GIT_ Params, but later upgraded to v1.0.1, changed to husky_ GIT_ PARAMS。

lint-staged

There is a commit githook. Can we beautify the code format and fix the problem of eslint. That’s what lint staged does.

Use tolint-stagedThe tool is used to identify the files added to the stage area, that is, only the current modified files are scanned each timegit addThe files added to the stage area can be scanned, and the incremental code can be checked.

Install lint staged

npm i -D lint-staged

The configuration of lint staged is as follows:

"lint-staged": {
    "*.{js,jsx,vue,ts,tsx}": [
        "vue-cli-service lint",
        "git add"
    ]
}

ls-lint

In larger projects, we need to specify the naming format of files. As follows:

1. Folder & file
Use camelCase (small hump), such as:
text
Folder. / layout /
File name iiapHeader.vue

Ls lint helps us to automatically verify the file naming specification, which saves the trouble of convention. We only need to verify the file naming specification when submitting

Add the following command to NPM

"scripts": {
    "ls-lint": "ls-lint"
},

.ls- lint.yml The file configuration is as follows:

ls:
    .vue: PascalCase
    .js: kebab-case
    .config.js: lowercase
    .ts: camelCase | PascalCase
    .d.ts: camelCase | kebab-case
    .spec.ts: camelCase | PascalCase
    .mock.ts: camelCase
    .vdom.js: kebab-case
    .spec.js: kebab-case

ignore:
    - dist
    - test
    - .babelrc.js
    - .eslintrc.js
    - .prettierrc
    - .github
    - .git
    - node_modules

Complete configuration

So we integrate the whole workflow:
Code style unification > eslint optimization > file naming specification > submission specification

We created:

  • .ls-lint.yml
  • commitlint.config.js

package.json to configure:

"scripts": {
    "ls-lint": "ls-lint"
},
"gitHooks": {
    "pre-commit": "ls-lint && lint-staged",
    "commit-msg": "commitlint -e $HUSKY_GIT_PARAMS"
},
"lint-staged": {
    "*.{js,jsx,vue,ts,tsx}": [
        "vue-cli-service lint",
        "git add"
    ]
}