Standardized specification

1. Standardization introduction

Standardization is an important part of our practice of front-end engineering. Here, standardization is introduced from the following aspects:

• Why should there be a standard

  • Software development requires collaboration of many people

  As the saying goes, “no rules, no standards” is the same for people to do things, especially in the development industry, it is necessary to have a rigorous working attitude -> in most cases, software development is not a single person’s work, it is required to cooperate with many people

  • Different developers have different coding habits and preferences
  • Different preferences increase project maintenance costs
  • Each project or team needs to have clear and consistent standards

  Get the project or team members to work to the same standards -> avoid the hassle of disagreements

• Where do you need a standard during development

  • Code, documentation, even the commit log

  • An artificially written success during development

  • Code standardization is of Paramount importance

    Code specification largely determines the quality of the project and also determines the maintainability of the project -> in order to facilitate the later maintenance and team members to read generally, the code style will be uniform requirements -> here generally include:

    • Unify Spaces around keywords and operators
    • Uniform code indentation
    • Specifies whether to end with a semicolon
    • Uniform naming conventions for variables or functions

• Methods of implementing standardization

  • Coding predecessors are standard conventions

    The initial implementation of the standardized operation is very simple. It only needs to agree a standard that can be implemented in advance -> then carry out their development work according to the standard -> finally, in the code-review process, the corresponding standard will be checked according to the agreed standard

    => However, there will be many problems in the implementation of standardization only by means of artificial agreement:

    • Artificial constraints are unreliable
    • It’s also hard for developers to remember every rule

  • Lint is implemented by tools

    Through the special tools to ensure the implementation of standardization relative to human inspection -> tool inspection is more rigorous and more reliable -> at the same time can also cooperate with automated tools to achieve automated inspection -> this standardization is easier to get quality assurance

    => Normally we use tools to find irregularities in a project and this process is called Lint -> The reason why Lint is called is: In the early days of C, there were some common code problems that the compiler couldn’t catch -> someone developed a tool called Lint to check for these problems before they were compiled so that they wouldn’t cause unnecessary problems later -> All subsequent tools like this were called Lint or “Lint” Linter -> Ex: the most common front-end ESLint, StyleLint, and so on

• Common normalization implementation

  • ESLint tool
  • Customize the ESLint validation specification
  • ESLint support for TypeScript
  • ESLint combines automation tools or Webpack
  • A derivative of ESLint
  • Use of the StyleLint tool
  • Git Hock/ESLint/Git Hock/ESLint/Git Hock

2. ESLint is introduced

It’s now much more efficient to use tools to validate projects -> here’s ESLint:

• The most mainstream JS Lint tools specialize in checking JS code quality

• ESLint makes it easy to unify developer coding styles

  Ex: use of indentation, newlines, semicolons, and whitespaces -> ESLint can also help you find irregularities in code. Ex: defining variables that are not used, declaring variables after they are used, always choosing double equal (==) symbols when comparing, etc

• ESLint can help developers improve their coding capabilities

  If you write code that finds a bunch of problems every time you do Lint -> most of these problems are bad coding habits -> over time you’ll remember the problems and avoid them the next time you code -> over time your coding ability will naturally improve

3. ESLint installation

Here is some work before ESLint uses -> ESLint installation and validation

ESLint installation steps:

• Initialize the project

• Install ESLint modules as development dependencies

  ESLint is a node-based NPM module -> install the ESLint module via NPM or YARN

• Verify the installation by running CLI commands

  After the installation is complete, you can run simple commands to check whether the installation is successful

Initialize package.json from the command line

yarn init --yes
Copy the code

Install the ESLint module from the command line

cnpm i eslint -D
Copy the code

As for the present stage Seldom global installing a module – > because most cases are dependent on specific projects a module – > install the module in local let it together with the project management will be more reasonable – > and others to your project after don’t need to separate care project depends on what the global module directly through the NPM Install allows you to install the necessary tool modules -> this also improves the maintainability of the project from the side => Since the ESLint module provides a CLI program, there will be an extra ESLint executable on the node_modules/.bin project after installation The CLI program can then be used to detect problems in the code

View the version of ESLint from the command line

Yarn eslint-version or NPX eslint --versionCopy the code

Print out the version of ESLint -> There is no need to decide whether to use NPM or yarn -> There is no absolute difference between the two. Each has its own advantages. Use either version according to your team/project’s specific requirements

4. Get started quickly with ESLint

First complete project initialization and ESLint module installation; ESLint check steps:

• Write the “problem” code

• Use ESLint to perform code detection

• Complete the ESLint use configuration

  ESlint must be configured for the first time before it can be used properly

Complete project initialization and ESLint installation

Create a new prepare.js in the project root directory and edit prepare.js

const foo = 123


function fn () {
  console.log('hello')
  
  	console.log('eslint')
  
  
}


fn(
  
  syy()
Copy the code

Run ESLint from the command line to find the problem in the above code

Follow ESLint orders need to take specific file path – > here path can also be a wildcard Because it can realize batch check – > choose here is that the specific path to the file

yarn eslint ./prepare.js
Copy the code

Run the following command: The terminal displays an error message:

Run esLint –init with an error message

yarn eslint --init
Copy the code

The console prints out deliverable issues:

• Syntax error: well understood Ex: the call to the fn() method in the above code
• Ex: This code defines an unused variable foo or calls a function syy that does not exist
• Code style: It is best to understand that the initial expectation of ESLint is that ESLint will be able to find problems with coding style Ex: indented and newlines in code are inconsistent

Select To check syntax, find Problem, and enforce code style here

Q2: What type of modularity is used in your project?

The options here determine whether your code will allow the specified syntax or calls -> allow global require and exports functions if you select CommonJs -> use import() and export syntax if you select ESM -> None of these is not used in this code

=> Q3: Which framework is being used?

None of these

=> Q4: Do you use TypeScript in your code?

This one doesn’t use the input N

=> Q5: What environment will your code run in?

I’m gonna go ahead and select Browser

=> Q6: How do you want to define the project code style?

In general, choose: mainstream code style on the market -> so that if new members join the project can better and faster adapt to our style

=> Q7: Which is the mainstream style in the market?

After the selection -> three mainstream styles are given

Among them, Airbnb and Google are the specific coding norms of these two companies respectively -> and Standard is a set of norms in the community -> Individuals usually like standard specification: the biggest characteristics: You don’t have to put a semicolon at the end of the statement -> Standard and what you choose is up to you, right

=> Q8: What format do you want your configuration files to be stored in?

I recommend using the JavaScript format -> add some criteria in the configuration file to determine whether to enable certain functions

After selecting, the terminal prompts you to install additional plug-ins -> select Y -> NPM to install these plug-ins

Eslintc.js -> Run ESLint to verify prepare.js from the command line

yarn eslint ./prepare.js
Copy the code

After execution: The terminal detects an error

=> The first thing found here is a syntax error -> modify the fn() function call in prepare.js

Perform the ESLint check again from the command line

This time the terminal will find more errors: why didn’t these errors be detected just now -> The reason is: ESLint will not be able to check the code or style when there is a syntax error in code -> in this case, you can use the –fix parameter to auto-correct most code style problems -> this is done by –fix

The code style is fixed with the command line argument –fix

yarn eslint ./prepare.js --fix
Copy the code

After execution: the style of the code is automatically fixed -> But you have not developed good coding habits, I suggest you manually change the error messages at the beginning to impress you => here the console also prints out two problems:

=> Modify prepare.js: remove the definition of foo and the call to syy()

Running ESLint again -> does not report an error

** Basic functions of ESLint: 1. You can find problems in code -> Problems include syntax errors, code irregularities, and style inconsistencies. 2. ESLint can fix most problems with code style **

5. ESLint configuration file parsing

Here’s an in-depth look at ESLint configuration files: before Through the command eslint – init created under the root directory of the project. The slintRC. Js configuration file In this file to write configuration will affect the current directory and all subdirectories file – > under normal circumstances Is not going to manually modify the configuration file If you need to enable or disable certain verification rules and modify the configuration items in the configuration file => Next: Check the configuration contents in the configuration file

Do project initialization and ESLint initialization ahead of time

Create configuration.js in the root directory

Sample code will be written in it to show the results of the configuration file changes

Open configuration file

Since the configuration file ends up running in the Node environment, you can see that a configuration object is exported in CommonJs mode. There are four configuration options in this configuration object: 1. env 2. extends 3. parserOptions 4. rules

5.1. ESLint configuration item -env: Flags the environment in which the current code is run

We all know that JS has different apis that can be called in different runtime environments, and many of these apis provide an Ex for handling as a global member: In the browser environment, you can use the window and document objects directly. In the node environment, these objects do not exist => env: ESLInt determines if a member is available based on the current configuration environment -> to avoid using non-available members in code -> Ex: The browser in the current configuration: True means that the current code will run in the browser environment -> then you can use global objects such as document or window directly in the environment -> Each environment has a set of predefined global variables that are allowed to be used once the environment is turned on

Edit the configuration file to change the browser value to false

//.eslintrc.js
env: {
  browser: false.es2020: true},...Copy the code

Edit the configuration. Js

document.getElementById("#abc")
Copy the code

Run ESLint from the command line to check configuration.js

yarn eslint ./configuration.js
Copy the code

You can see: There is no report document undefined error – > at this moment because when generating ESLint configuration choice standard style The final configuration is also inherited the standard configuration – > in the standard configuration made some specific configuration At this moment The document and the window is can be used in any environment = > standard configuration can be found in the configuration file is to prove – > because extends the rules of the load is to look for eslint – config – standard file name – > Find eslint-config-standard under node_modules: this module exports the configuration of a JSON file. Find and open eslintrc.json

This file sets document, Navigator, and Window to global-read-only members via globals, and the current project configuration inherits from this file, so the previous env setting does not affect the use of document -> For this reason, you can use a global member in the window

Use alert in configuration.js

//document.getElementById("#abc")
alert(11)
Copy the code

Run ESLint checks on the command line

yarn eslint ./configuration.js
Copy the code

Running the code will tell the terminal that the alert is not defined

=> This proves that the env option is based on the configured environment information to determine whether the global member is available. => Which environments can be configured for env?

You can enable multiple environments at the same time. Ex: Set Browser and Node to true so that the global members used in both environments can be used at the same time

5.2. ESLint configuration item-extends: Extends some shared configuration

Extends: extends extends extends some shared configuration Ex: Most of the time, if you want to share an ESLint configuration between multiple projects -> you can define a common configuration file or configuration module and then extend that configuration or file in extends => The property value can be an array -> It can inherit multiple shared configurations at the same time which will be used later

5.3. ESLint Configuration Item-parserOptions: Sets the configuration of the syntax parser

ECMAScript has released a number of syntaxes in recent years. The keyword Ex: let const -> controls whether a particular version of the ES syntax is allowed

Edit the eslintrc. Js

. .parserOptions: {
  ecmaVersion: 5},...Copy the code

After the changes, there is no way to use the new ES6 features in your code

Edit the configuration. Js

const csa = 222
Copy the code

Run ESLint to check code from the command line

yarn eslint ./configuration.js
Copy the code

The console prints an error message:

If the ecmaVersion is lower than 2015, the sourceType cannot be module -> because ESModules are a new feature in ES2015, whereas in standard configuration the sourceType is set to module

Modify standard configuration file eslintrc.json: set sourceType to script

. ."sourceType": "script".Copy the code

Run esLint again to check the code: Error message ->

It is also important to note that the version configuration in parserOptions only affects the syntax check and does not mean that certain members are available -> if the global member Ex: Promise is provided by ES2015, it is still controlled by the ES2016 option in env

Modify. Eslintrc. Js

module.exports = {
  env: {
    browser: false.es6: false},... .parserOptions: {
  	ecmaVersion: 2015},... }Copy the code

Edit the configuration. Js

const foo = 1
let csa = 2
let a = new Promise(a)Copy the code

Run ESLint to check configuration.js(yarn eslint./configuration.js) -> console error: Promise is not defined=> Whether a specific member is available needs to be defined by the environment

5.4. ESLint configuration item-rules: Configures each validation rule in ESLint to be on or off

ESLInt configuration item: rules -> Enable/disable for each check rule -> Enable/disable for each check rule by turning on a property in rules. Property name built-in rule name property values can be three:

• Off: Disables the rule
• Warn: sends a warning
• Error: An error is reported

Edit the eslintrc. Js

. .relues: {
  'no-alert': 'error'
}
Copy the code

Edit the configuration. Js

alert('cs')
Copy the code

Run the ESLint command to check configuration.js(yarn ESLint./configuration.js) -> Error ‘alert’ is not defined

=> What rules can be used specifically? -> ESLint provides a list of all the built-in validation rules available on the ESLint website -> The standard currently in use has a number of validation rules enabled that basically meet the validation requirements. If needed, you can configure them according to your own needs by modifying the configuration items in rules

5.5. ESLint configuration item – globals

This option is used to declare an additional global member Ex that can be used in code: You can add a new JQuery object with a value of readonly -> so that your code can use JQuery -> directly without any error

Edit the eslintrc. Js

. .globals: {
  "jQuery": "readonly"
}
Copy the code

Edit the configuration. Js

. jQuery('#cas')
Copy the code

Running ESLint to verify configuration.js -> does not prompt JQuery use error -> this is what globals does

6. ESLint configuration comments

Configuration comments can be interpreted as commenting the configuration directly in a script file -> then performing code validation -> why do you do this? One or two rule violations are inevitable when using ESLint during actual development — you can’t override a validation rule configuration because of one or two points in your project — > So in that case you can use ESLint’s configuration comments to resolve the issue => Do some preparation: Json, install the ESLint module, create eslint-configuration-comments.js in the root directory, and create the ESLint configuration file:.eslintrc.js in the root directory

Edit eslint – configuration – comments. Js

// Define a normal string in which business needs to use the ${} literal placeholder, but standard style does not allow this
const str1 = "${name} is a coder"

console.log(str1)
Copy the code

Run ESLint to check eslint-configuration-comments.js

yarn eslint ./eslint-configuration-comments.js
Copy the code

Running command console error:

You can use comments to temporarily disable the current rule. The syntax for these comments can be described in the official ESLint documentation

Edit eslint – configuration – comments. Js

In this case, eslint-disable-line -> allows ESLint to selectively ignore this line of checks while working

const str1 = "${name} is a coder" // eslint-disable-line

console.log(str1)
Copy the code

Re-running ESLint to check the eslint-configuration-comments.js file -> console does not report the previous error message:=> Use this to solve the problem: if there are multiple problems on a line, all problems are ignored -> Better to use eslint-disabled-line + the name of the rule to disable

Edit eslint – configuration – comments. Js

const str1 = "${name} is a coder" // eslint-disable-line no-template-curly-in-string

console.log(str1)
Copy the code

Run the ESLInt check:= > ESLint here at work when they will just ignore the specified rules Other rule still can be normal found = > annotation approach not only used to disable some rules Can also declared a global variable, modify a rule configuration, temporary began a certain environment and so on – > if you need can get through itEslint. Cn/docs/user – g…For specific use

7. ESLint with automation tools

We all know that ESLint is a stand-alone tool if you are currently in a project with automated workflows -> it is recommended that you integrate ESLint into automated workflows -> this has two advantages:

• ESLint will definitely work after integration

  Automated builds are guaranteed in automated workflows. Integrating ESLint into the build process ensures that ESLint will work

• Unified management with the project is more convenient

  The integration also makes it easier to manage and the project-related commands will be more uniform without Gulp and ESLint running between them

=> Preparatory work:

• From github.com/zce/zce-gul… Cloning project
• The dependency installation is complete
• The ESLint module installation is complete
• The gulp-esLint module is installed

Open the gulpfile. Js

Fold code -> Find the build task function that builds JS: A simple analysis shows that the JS build task uses Babel to convert source code. What we need to do now is to integrate ESLint operations into it -> because Gulp is a pipe working mechanism and ESLint integration should be done before Babel conversion ESLint -> Otherwise the code will no longer be true source code after Babel

Edit gulpfile. Js

.const script = () = > {
  return src('src/assets/script/*.js', { base: 'src' })
  .pipe(plugins.eslint())
  .pipe(plugins.babel({ presets: ['@babel/preset-env'] }))
  .pipe(dest('temp'))
  .pipe(bs.reload({ stream: true}}))...module.exports = {
  clean, build, develop, script
}
Copy the code

Then the current script task will perform ESLint on JS code before compiling Babel

Execute script tasks using gulp

yarn gulp script
Copy the code

After execution, the console reported an error:-> No ESLint configuration file found

Run the eslint script command again

This time the ESlit check was performed normally

Error code was intentionally written in mian. Js

.const a = 1
Copy the code

Run the eslint script command

This command can also be executed normally, which makes no sense -> since the initial assumption was that ESLint would be able to detect a problem and terminate subsequent compilation tasks -> why it succeeded here: By default, the ESLint plugin will only check for problems in the code and will not give any feedback based on the results. After ESLint completes processing, use ESLint’s format method to print the error message -> in the console. Then use ESLint’s failAfterError method to allow ESLint to terminate the task pipeline directly after checking for an error

Edit gulpfile. Js

.const script = () = > {
  return src('src/assets/script/*.js', { base: 'src' })
  .pipe(plugins.eslint())
  .pipe(plugins.eslint.format())
  .pipe(plugins.eslint.failAfterError())
  .pipe(plugins.babel({ presets: ['@babel/preset-env'] }))
  .pipe(dest('temp'))
  .pipe(bs.reload({ stream: true}}))...Copy the code

Run the script task again (yarn gulp script) on the command line -> The error message is displayed in the console:-> ESLint is now integrated into the JS editing task

8. ESLint with Webpack

8.1 ESLint with Webpack configuration

If you are currently developing a project that uses Webpack packaging, ESLint can also integrate into it -> only Webpack does not integrate into ESLint as a plugin, but via the Loader mechanism => Webpack before the module is packaged -> So ESLint can be integrated into Webpack as a Loader -> this allows ESLint to verify JS code before packaging it => Preparations in advance:

• Through github.com/zce/zce-rea… Cloning of warehouse

• Installing the corresponding module

• Install the ESLint module

• Install the ESLint-Loader module

• Initialize the.eslintrc.js configuration file

  A normal React app is built using Webpack instead of using the official CLI tools

Edit webpack. Config. Js

const HtmlWebpackPlugin = require('html-webpack-plugin')
module.exports = {
  mode: 'production'.entry: './src/main.js'.module: {
    rules: [
      // Currently all modules are handled by Babel-Loader. If you want to integrate ESLint with ESLint, you also need to use eslint-Loader to process them before babel-Loader -> because the modules are installed before babel-Loader
        / / here directly amend the JS use the Loader to the array Then eslint - loader on the back of the array - > it is important to note here: the order of the loader - > after the loader from here forward
        // Add a Loader rule to the JS file -> Add an enfore attribute to the rule with the value pre: Ensure that loaders configured in this rule have priority over other loaders (recommended).
      {
        test: /\.js$/,
        exclude: /node_modules/,        
        use: 'babel-loader'
      },
      // The second way
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: 'eslint-loader'.enfore: 'pre'},... ] },plugins: [
      new HtmlWebpackPlugin({
      	template: 'src/index.html'}})]Copy the code

Run the Webpack command on the command line

yarn webpack
Copy the code

After execution, the console reported an error:-> This is how ESLint is integrated into Webpack via Loader

8.2. Subsequent configuration of ESLint with Webpack

Eslint has already been integrated into webPack-using projects using eslint-Loader -> The next step is to add the corresponding esLint configuration to complete the subsequent code checks

View. Eslintrc. Js

The configuration here is just fine for the React project -> but the Webpack error (see 7.1) => find main.js and simply analyze the code itself-> Here React is not actually used -> here React is required after JSX code is compiled -> in this particular case ESLint will have to rely on some extra plug-in: eslint-plugin-react

Install eslint-plugin-react from the command line

cnpm i eslint-plugin-react -D
Copy the code

After installation, go to the node_modules directory and find the eslint-plugin-react module -> This module defines a number of validation rules that are specific to the React project -> Want to use these rules: This is configured using the plugins attribute in.eslintrc.js

Edit the eslintrc. Js

module.exports = { ...... .rules: {
  	// The value of the attribute can be set to Error/ WARN /off or 2/1/0
  	'react/jsx-uses-react': 2.// This rule prevents React from defining errors that are not being used
	},
  // The plugins value is an array. The members of the array can be directly specified to use certain plugins (the name of the plugin needs to be omitted from eslint-plugin).
  // After configuration, all rules in the Eslint-plugin-react module can be used
  plugins: [ 'react']}Copy the code

Perform Webpack packaging from the command line

yarn webpack
Copy the code

After execution: The console error message indicated that the previous React error did not appear=> Use the same method here -> replace it with a different rule: react/jsx-uses-vars

Edit the eslintrc. Js

module.exports = { ...... .rules: {
  	'react/jsx-uses-react': 2.'react/jsx-uses-vars': 2
	},
  plugins: [ 'react']}Copy the code

Run the Webpack package

The console does not output errors -> this is what plugins are for and basic use but for most ESLint plugins they do provide contributed configurations to reduce the cost of using them => the eslint-plugin-react used here exports two shared configurations: Recommended and All -> and now we use recommended -> this shared configuration can be used directly by inheritance -> but the syntax for inheritance is: plugin: plug-in name/shared configuration name

Edit the eslintrc. Js

module.exports = { ...... .extends: [
  	'standard'.'plugin:react/recommended']... .rules: {
  	 /* 'react/jsx-uses-react': 2, 'react/jsx-uses-vars': 2 */
	}/*, plugins: [ 'react' ]*/
}
Copy the code

The result of performing Webpack packaging is the same as without a shared configuration

9. Modernize projects to integrate with ESLint

With the popularity of frameworks like React or Vue, the ecology of frameworks has been very improved and the most obvious feeling is: Developing a React or Vue based project currently doesn’t require you to configure Webpack or ESLint engineering tools. The official CLI tools are already integrated with them => create one here using vue-CLI Vue.js as a demonstration

Use cli to install VUE

cnpm i @vue/cli -g
Copy the code

Run the vue create XXXX command to create a project

vue create syy-vue-app
Copy the code

Console interaction information:

One thing to noteLint on save: Verify automatically at Webpack build time: Lint and fix on commit: If a file is modified, Webpack will automatically compile it; if a file is modified, Webpack will automatically compile it; Commit -> use Git hooks to automatically verify the current code before git commit -> This ensures that all the code committed to the repository is verified

=> After the operation is complete -> vue-cli automatically installs the dependencies and creates the basic project structure at the end during which ESLint is integrated

Go to project -> Start project from the command line

cd syy-vue-app
npm run serve
Copy the code

Edit SRC /main.js to deliberately add error code

.const a = 1
Copy the code

After saving, the console output error message:-> In this way, developers do not need to spend too much time on the configuration and use of the tools. Developers can focus on the development of business functions

10. ESLint checks TypeScript

TypeScript is increasingly used in front-end projects. Here’s how ESLint validates TypeScript code: A case project, NPM initialization, ESLint module installation, TypeScript module installation– > this note must be installed TypeSc module Otherwise in the subsequent ESLint configuration file will be generated an error – > for Lint TypeScript code Could have been used before tslint tools But then tslint official put up the maintenance Instead, we suggest that we use ESLint with TypeScript plugins to implement TypeScript validation

Initialize the ESLint configuration action

yarn eslint --init
Copy the code

One caveat here: Select Yes -> when a TypeScript module is involved in the problem delivery. The last interaction requires the installation of two additional modules that ESLint requires to check TypeScript code

After that, you can use ESLint directly to check TypeScript code

Editing the ts

function foo (ms: string) :void {
  console.log(msg)
  
}

foo("hello TS ~")
Copy the code

View. Eslintrc. Js

The reason you need to configure a parser is because TypeScript has a lot of special syntax compared to normal JS code

Verify index.ts by running the command

yarn eslint ./index.ts
Copy the code

After execution, the console reported an error:

11. StyleLint

StyleLint checks for normal CSS code

In addition to JS code that needs to be Lint, CSS code also needs to be Lint -> CSS Lint uses the StyleLint tool to do this

StyleLint:

• Provides default code checking rules
• Provides quick invocation of the CLI tool
• Supports the Sass Less PostCSS through plug-ins
• Supports Gulp or Webpack integration

=> Preparation: NPM initialization, CSS and Sass file preparation

Install the StyleLint module on the cli

cnpm i stylelint -D
Copy the code

After the installation, you can find the stylelint CLI command in the node_modules/.bin directory. Once you have this command, you can check the style file code with this command

Run StyleLint on the command line to check index. CSS

yarn stylelint ./index.css
Copy the code

Console output error: no corresponding configuration file was found

Manually add.stylelintr.js to the root directory and edit it

The StyleLint configuration items are basically the same as those in ESLint

module.exports = {
  StyleLint does not have any shared configuration available internally, so you need to install some modules of your own
  extends: "",}Copy the code

Install stylelint-config-standard

Stylelint-config-standard: indicates the stylelint shared configuration module

cnpm i stylelint-config-standard -D
Copy the code

Edit the stylelintrc. Js

After installation, use the module directly -> but there are some differences from ESLint: the shared configuration name here must be a completed module name

module.exports = {
  extends: "stylelint-config-standard"
}
Copy the code

Check index.css again on the command line

yarn stylelint ./index.css
Copy the code

This time you can find the problem in the CSS code:-> You can also automate most problems directly by using the –fix command line argument

11.2. StyleLint checks the Sass code

If you need to use StyleLint to verify Sass code in a project -> install another module: stylelint-config-sass-Guidelines -> Install Sass plug-in with StyleLint in this module

Use the cli to install stylelint-config-sass-guidelines

cnpm i stylelint-config-sass-guidelines -D
Copy the code

Edit the stylelintrc. Js

module.exports = {
  extends: [
    "stylelint-config-standa"."stylelint-config-sass-guidelines"]}Copy the code

Run the StyleLint command to check index.sass

yarn stylelint ./index.sass
Copy the code

StyleLint detects a problem with Sass code after execution:< span style = “box-sizing: border-box; color: RGB (50, 50, 50); line-height: 22px; font-size: 16px! Important; word-break: block;

If you want to integrate StyleLint into Gulp or Webpack, you can refer to ESLint’s integration method

12. Use of Prettier

Prettier is a common front-end code formatting tool used frequently in recent years. It is very powerful and can format almost all types of code files. In daily use, Prettier can also be used to automatically format code or for markdown In short, Prettier can easily implement the standardization standards in front-end projects and its use is very simple

=> Prepare in advance: prepare different code files that can be encountered during daily front-end development

Install Prettier on the CLI

yarn i Prettier -D
Copy the code

After the prettier command on the prettier module is used to format the test code

Run the prettier command to format style. CSS

yarn prettier ./style.css
Copy the code

After the command is executed: The console outputs the formatted CSS code -> by default, the prettier command outputs the formatted CSS code directly to the console -> To overwrite the formatted CSS code directly -> add the command line parameter “write” to the end

Run the prettier command to overwrite the formatted code on the source file

yarn prettier ./style.css --write
Copy the code

After the Prettier command is executed, the Prettier command automatically formats the file

Using wildcards on the command line, format all the code at once

yarn prettier . --write
Copy the code

After the command “prettier” is executed, all codes are formatted and the source file is overwritten

13. Git Hooks work mechanism

Here are Git some Hooks with content is introduced Because you need to use in the subsequent ESLint and the combination of the Git Hooks – > currently have to understand the importance of code standardization and how to through the use of some tools to ensure that the code specification – > However, there are still some problems left out in the process. Not performing Lint work before the code is submitted to the repository -> This can result in the entire project not passing CI -> So the Lint tool loses its meaning -> The Lint tool is used to ensure that the code is submitted to the repository without problems And the format is good -> how can we solve this problem? => Force Lint to commit code using Git Hooks

=> Git Hooks introduction

• Git Hooks are also called Git Hooks, and each hook corresponds to a task

  Each hook is attached to a specific Gti operation Ex: Commit push

• Shell scripts allow you to write specific actions to be performed when the hook task is triggered

  Find a specific hook by writing a specific shell script that defines the task to be performed when the hook action is triggered: pre-commit hook -> trigger before commit

14. ESLint combines Git Hooks

Requirement: Forcing Git hooks to Lint code before it’s committed => Here’s a real problem: Currently, many front-end developers are not good at using shell scripting, which is currently a must, so someone developed an NPM module: The use of Husky -> Git Hooks can be implemented without having to write shell scripts

=> Initial preparation: NPM initialization, ESlint configuration initialization script, used to test index

Install the HUSky module from the command line

cnpm i husky -D
Copy the code

The editor package. Json

{
  "script": {
    "ESLint": "eslint ./index.js"},... ."husky": {
  	"hooks": {
  		"pre-commit": "npm run ESLint"}}}Copy the code

Editing the js

const a = 1

3333
Copy the code

Commit to the repository through the command line code

git add .
git commit -m '111'
Copy the code

Lint error => Console output after execution:-> < p style = “text-align: center; Lint operations will be performed before the code is committed -> Code will not be committed to the repository if there is an error in Lint -> This already allows the developer to check the code before committing => But if you want to do some subsequent operations after the check Ex: Format the examined code or add the formatted code to the temporary area -> At this point husky becomes insufficient

Lint-staged: Husky continues to provide some additional functionality

Lint-staged is installed from the command line

cnpm i lint-staged -D
Copy the code

The editor package. Json

{... ."script": {
    "ESLint": "eslint ./index.js"."preCommit": "lint-staged"},... ."husky": {
  	"hooks": {
  		"pre-commit": "npm run preCommit"}},"lint-staged": {
    "*js": [
      "eslint"."git add"]}}Copy the code

Run the commit command

git add .
git commit -m '222'
Copy the code

After execution, it is found that the esLint and Git add operations have been executed in sequence-> This makes it possible to enforce validation of the submitted code before it is submitted, and also to perform other operations after the latter verifies the code before it is submitted