preface

Write nuggets for the first time, write bad please forgive me ~

Without going into the basics of ESLint, how about the difference between plugins and extends

The plugins plugin

Eslint rules can be configured using rules, as a simple example:

//	.eslintrc.js
module.exports = {
	rules: {
    'indent': 'off'}}Copy the code

However, there are some custom ESLint checking requirements for different scenarios and specifications. If esLint does not provide optional rules by default, some extensions may be needed.

The plugin adds some checking rules to ESLint, for example: {eslint-plugin-react} eslint-plugin-react {eslint-plugin-react} jsx-boolean-value {eslint-plugin-react}} For details, see eslint-plugin-react.

//	eslint-plugin-react
module.exports = {
  rules: {
    'jsx-boolean-value': {
      meta: {
        docs: {
          description: 'Enforce boolean attributes notation in JSX'.category: 'Stylistic Issues'.recommended: false.url: docsUrl('jsx-boolean-value')},fixable: 'code'
      },
      create(context){}}// ...
  },
  configs: {
    // ...
    // This is related to extends}}Copy the code

How can eslint-plugin-React be used in your own projects

Yarn add eslint-plugin-react –dev; / / eslint-plugin-react –dev

The second step is to load the plugins. Plugins only load plugins, so esLint can parse jSX-Boolea-value rules for checking. (A plugin library often has dozens of new rules, not every rule needs to be enabled, so it is time to configure the relevant check rules according to your needs)

//	.eslintrc.js
module.exports = {
  plugins: [
    'eslint-plugin-react'].rules: {
    'eslint-plugin-react/jsx-boolean-value': 2}}Copy the code

A new ESLint rule is now set.

Extends the integration

Combining plugins with Rules is a fundamental capability of ESLint, and extends can be seen as a best practice for integrating configuration scenarios.

Different ESLint rules need to be configured based on different requirements, styles, and specifications, but often similar projects need to configure similar rules. It would be less human to start from scratch with each project to select configuration rules; This is where extends comes into play.

I prefer to think of extends as a best practice for integrating esLint-style or ESLint plugins, where it is actually a copy of what someone else has configured.

As an example, eslint-plugin-React implements dozens of configuration rules. In order to make it easier for others to use it, it implements two best practices, all and recommened (see configs) by default.

Originally, you had to choose one by one, so you could use the best practices that had been officially configured. If you encounter rules that conflict with your own style or specification, you can simply redefine them in rules, because there are usually very few conflicting rules

module.export = {
	extends: [
    	'eslint-plugin-react/recommended']}Copy the code

Extends In addition to using the plugin’s config name loading method, packages named eslint-config-xxxx are also used. This is mainly because some best practices don’t require you to re-implement the rule checking method yourself, just export a copy of the ESLint configuration.