1. Introduction

No rules, no fangyuan, set in the front is also applicable. In a front-end project, everyone has different coding habits, styles, ides, etc., and if the code is not properly regulated, the submitted code will be very distinctive.

Therefore, we need to define specifications on the automation level, so that when other colleagues submit code, it is uniformly formatted code.

1.1 Project Initialization

Eslit + Prettier using the Vue CLI

vue create projectName
Copy the code

Select manual configuration:

Press the space bar to select: Router and Vux can be selected, or you can manually select:

Here’s the configuration I chose, the last ESLint + Prettier, do it yourself, or choose the Airbnb standard:

2. Integrate the EditorConfig configuration

EditorConfig helps maintain a consistent coding style for multiple developers working on the same project on different IDE editors. Configuration is as follows

# # http://editorconfig.org root = true [*] said all applicable charset = utf-8 # set file for utf-8 character set indent_style = space # indented style (TAB | Space) indent_size = # 2 # end_of_line indentation size = lf control line type (lf | cr | CRLF) trim_trailing_whitespace = true line # remove any white space characters of the first Insert_final_newline = true # Always insert a newline at the end of the file [*.md] # indicates that the following rules apply only to md files max_line_length = off TRIM_trailing_whitespace = falseCopy the code

VSCode requires a plug-in: EditorConfig for VSCode

Vscode will read the.editorConfig file in the root directory and set the formatting effect.

3. Use the prettier tool

Prettier Prettier is a powerful code formatting tool that supports JavaScript, TypeScript, CSS, SCSS, Less, JSX, Angular, Vue, GraphQL, JSON, Markdown, etc. Basically the front end can use the file format it can be done, is the most popular code formatting tool

3.1 installation prettier

npm install prettier -D
Copy the code

3.2 Configuring the. Prettierrc file

  • UseTabs: Use TAB or space indent, select false;
  • TabWidth: if TAB is a space, select 2 Spaces;
  • PrintWidth: When the line length is 80 characters, some people prefer 100 or 120 characters;
  • SingleQuote: Use single or double quotes, select true, use single quotes;
  • TrailingComma: whether to add the trailingComma entered on multiple lines, set tonone;
  • Semi: Indicates whether to add a semicolon to the end of the statement. The default value is true.
{
  "useTabs": false."tabWidth": 2."printWidth": 80."singleQuote": true."trailingComma": "none"."semi": false
}
Copy the code

3.3. Creating. Prettierignore Ignores a file

/dist/*
.local
.output.js
/node_modules/**

**/*.svg
**/*.sh

/public/*
Copy the code

3.4. VSCode needs to install prettier’s plug-in

Prettier can be triggered in several ways:

  1. CTRL + S Save trigger (setting -> Formatting -> Format On Save);
  2. Alt + Shift + F formatting key trigger (make sure formatting is prettier)

If we change too many files and don’t want to format them one by one, we can configure a script in package.json:

 "prettier": "prettier --write ."
Copy the code

NPM run prettier would then be completely formatted.

4. Use ESLint to detect

We chose ESLint when we created the project earlier, so Vue will help us configure the ESLint environment we need by default.

VSCode requires the ESLint plugin to be installed:

Where esLint and Prettier collide

Install plugins :(if prettier is selected by vue when creating a project, these two plugins are installed automatically)

npm i eslint-plugin-prettier eslint-config-prettier -D
Copy the code

Add the prettier plugin:

  extends: [
    "plugin:vue/vue3-essential"."eslint:recommended"."@vue/typescript/recommended"."@vue/prettier"."@vue/prettier/@typescript-eslint",
    'plugin:prettier/recommended'
  ],
Copy the code

If the following custom formats are the same, the following formats overwrite the previous ones.

Git Husky and esLint

Although we have already required the project to use ESLint, there is no guarantee that the problems in ESLint will be resolved before team members submit code:

  • That is, we want to ensure that the code in the repository is esLint compliant;

  • Git commit: If the git commit does not conform to the ESLint specification, it will be automatically fixed by the specification.

So how do you do this? Husky tools are available:

  • Husky is a Git hook that triggers the various stages of git commit: pre-commit, commit-msg, and pre-push

How do you use Husky?

Here we can use the autoconfiguration command:

npx husky-init && npm install
Copy the code

Three things will be done here:

1. Install Husky-related dependencies:

2. Create the.husky folder in the project directory

npx huksy install
Copy the code

3. Add a script to package.json:

Next, we need to do one operation: on commit, execute the Lint script:

Git commit will automatically validate your code.

5.1 Git Commit Specifications

Git commits are usually committed in a consistent style so that you can quickly locate each commit for later version control.

But if writing these manually every time is a hassle, we can use a tool: Commitizen

  • Commitizen is a tool that helps us write normative Commit messages;

1. Install Commitizen

npm install commitizen -D
Copy the code

2. Install AND initialize THE Z-Xconventional – Changelog:

npx commitizen init cz-conventional-changelog --save-dev --save-exact
Copy the code

This time we need to submit code using NPX cz:

  • The first step is to select Type, the type of this update
Type role
feat New features
fix Fix the Bug (Bug fix)
docs Modify documentation
style Change code formats (white-space, formatting, missing semi Colons, etc.)
refactor Code Refactor
perf A code change that improves Performance
test When adding Missing tests
build Changing project builds or external dependencies (e.g. scopes: webpack, gulp, NPM, etc.)
ci Change the scripts commands in the continuous integration software configuration files and packages, such as scopes: Travis, Circle, etc
chore Changing the build process or ancillary tools (such as changing the test environment)
revert Code back
  • Step 2 Select the scope of this modification (scope)

  • The third step is to select the information to submit

  • Step 4 Submit detailed description

  • Step 5 is a major change

  • Step 6 Whether to affect an Open issue

We can also build a command in scripts to execute cz:

This allows you to select commit information from the command line using the NPM run commit script command.

5.2 Code submission verification

What if we standardize the commit style according to CZ, but some colleagues still commit according to non-standard format through Git commit?

  • We can restrict commits via commitlint;

1. Install @commitlint/ config-Conventional and @commitlint/ CLI

npm i @commitlint/config-conventional @commitlint/cli -D
Copy the code

2. Create the commitlint.config.js file in the root directory and configure commitLint

module.exports = {
  extends: ['@commitlint/config-conventional']}Copy the code

3. Use husky to generate the commit-msg file and verify the commit information:

npx husky add .husky/commit-msg 
Copy the code
  1. Copy NPX –no-install commitlint –edit to the file

The net effect is that only committed information looks like this before it passes the commit.