Что вы знаете о внешнем интерфейсе housekeeper package.json?

Эта статья участвовала в "Проект «Звезда раскопок»”, чтобы выиграть творческий подарочный пакет и бросить вызов творческим поощрительным деньгам.

Сегодня давайте взглянем на конфигурацию, связанную с файлом package.json служебной программы переднего плана. Полное понимание этих конфигураций поможет нам повысить эффективность разработки и стандартизировать наши проекты. Содержание статьи больше, рекомендуется сначала собрать и изучить!

В каждом интерфейсном проекте есть файл package.json, который является файлом конфигурации проекта.Общие конфигурации включают настройку запуска проекта, команды упаковки и объявление зависимых пакетов. Файл package.json — это объект JSON, каждый член объекта — это настройка текущего проекта. Package.json, как главный помощник интерфейса, тесно связан с нашей повседневной разработкой. Давайте внимательно посмотрим на этот файл.

Когда мы создаем новый проект, скаффолдинг часто помогает нам инициализировать файл конфигурации package.jaon, который находится в корневом каталоге проекта. При использовании шаблонов реагирования (create-react-app) для инициализации проекта содержимое его файла package.json выглядит следующим образом:

{
  "name": "my-app",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@testing-library/jest-dom": "^5.14.1",
    "@testing-library/react": "^11.2.7",
    "@testing-library/user-event": "^12.8.3",
    "react": "^17.0.2",
    "react-dom": "^17.0.2",
    "react-scripts": "4.0.3",
    "web-vitals": "^1.1.2"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },
  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ]
  },
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  }
}

Когда мы клонируем новый проект в локальный, нам нужно выполнить команду npm install (yarn install), чтобы установить файлы зависимостей, необходимые для проекта. При выполнении этой команды требуемые модули будут автоматически загружены в соответствии с информацией о конфигурации в файле package.json, то есть рабочей средой и средой разработки, требуемой проектом конфигурации.

Общие элементы конфигурации в package.json следующие: package.json.png

1. Обязательные атрибуты

Два наиболее важных поля в package.json — это имя и версия. Они оба обязательны. В противном случае команда npm install не может быть выполнена нормально. npm предусматривает, что файл package.json однозначно идентифицируется по имени и номеру версии.

1. name

name легко понять, это название проекта, это строка. При именовании поля имени помните о следующих моментах:

Имя должно быть меньше или равно 214 символам, не может начинаться с «.» и «_» и не может содержать буквы в верхнем регистре (это связано с тем, что при публикации пакета на npm он получает собственный URL-адрес на основе этого свойства, поэтому он не может содержать небезопасные для URL символы (небезопасные для URL));
Имя можно передать в require("") в качестве параметра для импорта модуля, поэтому оно должно быть максимально коротким и семантическим;
Имя не может повторяться с именами других модулей.Вы можете использовать команду npm view, чтобы запросить, повторяется ли модуль.Если он не повторяется, будет выдано сообщение 404:

Если в пакете npm есть соответствующий пакет, будут отображены сведения о пакете:На самом деле, многие проекты, которые мы обычно разрабатываем, не публикуются на npm, поэтому стандартное имя или нет может быть не так важно, на нормальную работу проекта это не повлияет. Если его необходимо опубликовать на npm, поле имени должно соответствовать требованиям.

2. version

Поле версии представляет номер версии пакета проекта, который представляет собой строку. После каждого изменения проекта номер версии проекта должен быть изменен синхронно перед его выпуском. Спецификации для использования номеров версий следующие:

Название номера версии соответствует спецификации Semantic Versioning 2.0.0, а формат следующий:Основной номер версии Дополнительный номер версии Номер редакции, В нормальных условиях изменение основного номера версии является важным функциональным изменением, изменение вспомогательного номера версии — добавлением новых функций, а изменение номера версии — исправлением некоторых ошибок;
Если изменения определенной версии велики и нестабильны, она может соответствовать ожидаемым требованиям совместимости, и необходимо выпустить первую версию.Идентификатор и информация о компиляции версии: внутренняя версия (альфа), публичная бета-версия (бета). ) и версия-кандидат (rc, т.е. релиз-кандидат).

Вы можете запустить следующую команду, чтобы просмотреть информацию о версии пакета npm, взяв в качестве примера реакцию:

// 查看最新版本
npm view react version
// 查看所有版本
npm view react versions

При выполнении второй команды результат следующий:

2. Описательная информация

В package.jaon есть пять полей конфигурации, связанных с информацией об описании пакета проекта.Давайте посмотрим на значения этих полей соответственно.

1. description

Поле описания используется для описания пакета, которое представляет собой строку, которая позволяет другим разработчикам обнаруживать наш пакет в поиске npm.

2. keywords

Поле ключевых слов представляет собой массив строк, представляющих ключевые слова для этого пакета. Подобно описанию, он используется для увеличения экспозиции пакета проекта. Ниже приводится описание и ключевые слова пакета eslint:

3. author

Автор, как следует из названия, является автором, указывающим на автора пакета проекта. Он имеет две формы, одна из которых представляет собой строковый формат:

"author": "CUGGZ <xxxxx@xx.com> (https://juejin.cn/user/3544481220801815)"

Другой находится в форме объекта:

"author": {
  "name" : "CUGGZ",
  "email" : "xxxxx@xx.com",
  "url" : "https://juejin.cn/user/3544481220801815"
}

4. contributors

Contributors представляет участников пакета проекта. В отличие от автора, это поле представляет собой массив, содержащий всех участников. Оно также может быть записано двумя способами:

"contributors": [
  "CUGGZ0 <xxxxx@xx.com> (https://juejin.cn/user/3544481220801815)",
  "CUGGZ1 <xxxxx@xx.com> (https://juejin.cn/user/3544481220801815)"
 ]

"contributors": [
  {
  	"name" : "CUGGZ0",
  	"email" : "xxxxx@xx.com",
  	"url" : "https://juejin.cn/user/3544481220801815"
	},
  {
  	"name" : "CUGGZ1",
  	"email" : "xxxxx@xx.com",
  	"url" : "https://juejin.cn/user/3544481220801815"
	}
 ]

5. homepage

homepage — это адрес домашней страницы проекта, это строка.

6. repository

Репозиторий представляет собой адрес репозитория, в котором хранится код, обычно в двух формах. Первый находится в строковой форме:

"repository": "https://github.com/facebook/react.git"

Кроме того, система контроля версий может быть задана явно, в данном случае в виде объекта:

"repository": {
  "type": "git",
  "url": "https://github.com/facebook/react.git"
}

7. bugs

bugs представляет собой адрес, по которому проект отправляет проблемы, это поле является объектом, вы можете добавить адрес для отправки проблем и адрес электронной почты для обратной связи:

"bugs": { 
  "url" : "https://github.com/facebook/react/issues",
  "email" : "xxxxx@xx.com"
}

Наиболее распространенные ошибки — это страница с проблемами в Github, Выше указан адрес страницы с проблемами реакции.

3. Конфигурация зависимостей

Обычно наш проект зависит от одного или нескольких внешних пакетов зависимостей.В соответствии с различным использованием пакетов зависимостей их можно настроить в соответствии со следующими пятью свойствами: зависимости, devDependencies, peerDependencies, bundledDependencies, optionalDependencies. Рассмотрим значение каждого атрибута.

1. dependencies

Поле зависимостей объявляет необходимые зависимости в производственной среде проекта. При использовании npm или yarn для установки пакета npm пакет npm автоматически вставляется в этот элемент конфигурации:

npm install <PACKAGENAME>
yarn add <PACKAGENAME>

При использовании параметра --save при установке зависимостей вновь установленный пакет npm также будет записан в свойство зависимостей.

npm install --save <PACKAGENAME>

Значением этого поля является объект.Каждый член объекта состоит из имени модуля и соответствующих требований к версии, указывающих на зависимый модуль и диапазон его версий.

"dependencies": {
   "react": "^17.0.2",
   "react-dom": "^17.0.2",
   "react-scripts": "4.0.3",
},

Каждая конфигурация здесь представляет собой пару ключ-значение, где ключ представляет имя модуля, а значение представляет номер версии модуля. номер версии следуетОсновной номер версии Дополнительный номер версии Номер редакцииВ формате указывается:

Исправленная версия:Версия 4.0.3 приведенных выше реактивных скриптов является фиксированной версией, и при установке устанавливается только указанная версия;
Тильда:Например, ~4.0.3 означает установку самой последней версии 4.0.x (не ниже 4.0.3), что означает, что номера основной и дополнительной версии не будут изменены при установке;
вставка:Например, версия реакции выше ^17.0.2, что означает, что установлена последняя версия 17.x.x (не ниже 17.0.2), а значит, основной номер версии не будет изменен при установке. Если основной номер версии равен 0, знаки вставки и тильды ведут себя одинаково;
последняя: установить последнюю версию.

Следует отметить, что не ставьте тестовые или переходные зависимости в зависимости, чтобы избежать непредвиденных проблем в производственной среде.

2. devDependencies

Зависимости, объявленные в devDependencies, требуются на этапе разработки, такие как Webpack, Eslint, Babel и т. д., которые используются для помощи в разработке. Они отличаются от зависимостей тем, что их нужно устанавливать только на устройствах разработки без запуска кода в рабочей среде. Эти пакеты не нужны, когда пакет запускается, поэтому эти зависимости можно добавить в devDependencies, и эти зависимости по-прежнему будут устанавливаться и управляться, когда npm install указан локально, но не будут устанавливаться в производственной среде.

При установке пакетов с помощью npm или yarn новые установленные пакеты npm автоматически вставляются в этот список, если указаны следующие параметры:

npm install --save-dev <PACKAGENAME>
yarn add --dev <PACKAGENAME>

"devDependencies": {
  "autoprefixer": "^7.1.2",
  "babel-core": "^6.22.1"
}

3. peerDependencies

В некоторых случаях наш проект и модули, от которых он зависит, будут одновременно зависеть от другого модуля, но версии, от которых они зависят, будут разными. Например, наш проект зависит от версии 1.0 модуля А и модуля Б, а сам модуль А зависит от версии 2.0 модуля Б. В большинстве случаев это не проблема, две версии модуля B могут сосуществовать и работать одновременно. Однако существует ситуация, когда возникает проблема, когда эта зависимость будет открыта для пользователя.

Наиболее типичным сценарием является плагин, например, модуль А является плагином модуля Б. Модуль B, установленный пользователем, имеет версию 1.0, но подключаемый модуль A можно использовать только с модулем B версии 2.0. В это время, если пользователь передаст экземпляр версии 1.0 B в A, возникнет проблема. Следовательно, необходим механизм, напоминающий пользователю при установке шаблона о том, что если A и B установлены вместе, то B должен быть модулем версии 2.0.

Поле peerDependencies используется плагином для указания версии основного инструмента, который ему нужен.

"name": "chai-as-promised",
"peerDependencies": {
   "chai": "1.x"
}

Приведенный выше код указывает, что при установке модуля chai-as-promise основная программа chai должна быть установлена вместе, а версия chai должна быть 1.x. Если в проекте указана зависимость от chai версии 2.0, будет сообщено об ошибке.

Обратите внимание, что начиная с npm версии 3.0, peerDependencies больше не устанавливаются по умолчанию.

4. optionalDependencies

Если вам нужно поддерживать работу npm, даже когда пакет не может быть найден или установка пакета завершается с ошибкой, вы можете поместить пакет в объект optionalDependencies, и пакет в объекте optionalDependencies перезапишет пакет с тем же именем в зависимостях. , поэтому вам нужно сделать это только в одном месте.

Следует отметить, что поскольку зависимости в optionDependencies могут быть установлены неуспешно, необходимо выполнить обработку исключений, иначе при получении этой зависимости, если она не может быть получена, будет сообщено об ошибке.

5. bundledDependencies

Вышеупомянутые несколько элементов конфигурации, связанных с зависимостями, являются объектами, а элемент конфигурации bundledDependencies представляет собой массив.Некоторые модули могут быть указаны в массиве, и эти модули будут упакованы вместе при выпуске пакета.

Следует отметить, что значением в этом массиве полей должен быть пакет, объявленный в зависимостях и devDependencies.

6. engines

Когда мы поддерживаем некоторые старые проекты, могут быть особые требования к версии пакета npm или версии Node. Если условия не выполняются, проект может не запуститься. Чтобы проект заработал из коробки, в поле движки можно указать конкретный номер версии:

"engines": {
	"node": ">=8.10.3 <12.13.0",
  "npm": ">=6.9.0"
}

Следует отметить, что движки служат только в качестве описания, даже если установленная пользователем версия не соответствует требованиям, это не влияет на установку зависимых пакетов.

В-четвертых, конфигурация скрипта

1. scripts

scripts — это встроенная запись скрипта в package.json, представляющая собой конфигурацию пары "ключ-значение" Ключ — это исполняемая команда, которую можно выполнить с помощью npm run. В дополнение к выполнению основных команд сценариев вы также можете комбинировать предварительные и последующие операции для выполнения предварительных и последующих операций. Давайте сначала посмотрим на набор скриптов:

"scripts": {
	"dev": "node index.js",
  "predev": "node beforeIndex.js",
  "postdev": "node afterIndex.js"
}

Эти три файла js имеют консольное предложение:

// index.js
console.log("scripts: index.js")
// beforeIndex.js
console.log("scripts: before index.js")
// afterIndex.js
console.log("scripts: after index.js")

Когда мы выполняем команду npm run dev, вывод выглядит следующим образом:

scripts: before index.js
scripts: index.js
scripts: after index.js

Видно, что выполняются все три команды, а порядок выполнения predev→dev→postdev. Если команды сценариев имеют определенную последовательность, вы можете использовать эти три элемента конфигурации для настройки и выполнения команд соответственно.

Настроив свойство scripts, вы можете определить некоторые общие команды операций:

"scripts": {
  "dev": "webpack-dev-server --inline --progress --config build/webpack.dev.conf.js",
  "start": "npm run dev",
  "unit": "jest --config test/unit/jest.conf.js --coverage",
  "test": "npm run unit",
  "lint": "eslint --ext .js,.vue src test/unit",
  "build": "node build/build.js"
}

Эти сценарии являются приложениями командной строки. Их можно запустить, вызвав npm run XXX или yarn XXX, где XXX — имя команды. Например: npm run dev. Мы можем использовать любое имя для команды, а сценарий может быть любым действием.

Правильное использование этого поля может значительно повысить эффективность разработки.

2. config

Поле config используется для настройки параметров конфигурации при запуске скриптов следующим образом:

"config": {
	"port": 3000
}

Если вы запустите npm run start, поле порта сопоставляется сnpm_package_config_portВ переменных окружения:

console.log(process.env.npm_package_config_port) // 3000

Пользователи могут проходитьnpm config set foo:port 3001команда для переопределения значения порта.

5. Файлы и каталоги

Давайте посмотрим на свойства, связанные с файлами и каталогами в package.json.

1. main

Основное поле используется для указания загружаемого файла записи, который можно использовать как в браузере, так и в среде Node. Если мы публикуем проект как пакет npm, то при использовании require для импорта пакета npm возвращается свойство module.exports файлов, перечисленных в основном поле. Если это поле не указано, по умолчанию используется index.js в корневом каталоге проекта. Если не найдено, будет сообщено об ошибке.

Значение этого поля представляет собой строку:

"main": "./src/index.js",

2. browser

Поле браузера может определять входной файл пакета npm в среде браузера. Если пакет npm используется только на стороне веб-сайта, а его использование на стороне сервера строго запрещено, используйте браузер для определения файла входа.

"browser": "./src/index.js"

3. module

Поле модуля может определять файл ввода спецификации ESM пакета npm, который может использоваться как средой браузера, так и средой узла. Если пакет npm экспортирует пакет спецификации ESM, используйте модуль для определения файла записи.

"module": "./src/index.mjs",

требует внимания,Файлы .js используют стандартный синтаксис commonJS (require('xxx')),.mjs находится в синтаксисе спецификации ESM (импорт 'xxx').

Конфигурации, относящиеся к вышеуказанным трем файлам записей, различаются, особенно в разных сценариях использования. В веб-среде, если для загрузки ESM (модуля ES) используется загрузчик, порядок загрузки этих трех конфигураций следующий: браузер→модуль→основной, а если модуль CommonJS загружается с помощью require, порядок загрузки следующий: основной→модуль → браузер.

Когда Webpack создает проект, есть целевая опция, которая по умолчанию равна Web, то есть для создания веб-приложения. Если вам нужно скомпилировать некоторые изоморфные проекты, такие как проекты узлов, вам нужно только установить целевой параметр webpack.config.js на узел для сборки. Если модуль CommonJS или ESM загружены в среде Node, допустимо только основное поле.

4. bin

Поле bin используется для указания местоположения исполняемого файла, соответствующего каждой внутренней команде:

"bin": {
  "someTool": "./bin/someTool.js"
}

Здесь исполняемый файл, соответствующий команде someTool, — это someTool.js в каталоге bin, и someTool.js создаст символическую ссылку node_modules/.bin/someTool. Поскольку каталог node_modules/.bin/ будет добавлен в системную переменную PATH во время выполнения, эти скрипты можно вызывать напрямую через команды без пути при запуске npm. Поэтому в сокращенной форме можно записать следующее:

scripts: {  
  start: './node_modules/bin/someTool.js build'
}

// 简写
scripts: {  
  start: 'someTool build'
}

Все команды в каталоге node_modules/.bin/ можно запускать в формате npm run [команда].

Приведенная выше конфигурация предоставляет поле bin в пакете package.json, которое сопоставляется с именем локального файла, а затем пакет npm связывает этот файл с префиксом/исправлением для глобального введения. Или ссылку на локальный файл node_modules/.bin/ для использования в этом проекте.

5. files

Конфигурация файлов — это массив, описывающий список файлов, которые необходимо указать при установке пакета npm в качестве зависимости. Когда пакет npm опубликован, файлы, указанные файлами, будут отправлены на сервер npm.Если указана папка, будут отправлены все файлы в папке.

"files": [
    "LICENSE",
    "Readme.md",
    "index.js",
    "lib/"
 ]

Если есть файлы, которые вы не хотите отправлять, вы можете создать новый файл .npmignore в корневом каталоге проекта и описать в нем файлы, которые не нужно отправлять, чтобы предотвратить отправку ненужных файлов в npm. Формат этого файла аналогичен .gitignore. Файлы, записанные в этот файл, будут исключены, даже если они записаны в атрибуте files. Например, вы можете написать это в файле:

node_modules
.vscode

build

.DS_Store

6. man

Команда man — это команда справки в Linux, с помощью которой вы можете просматривать такую информацию, как справка по командам, справка по файлу конфигурации и справка по программированию в Linux. Если модуль node.js является глобальным инструментом командной строки, атрибут man в package.json может указывать адрес документации, которую ищет команда man:

"man": [
	"./man/npm-access.1",
	"./man/npm-audit.1"
]

В поле man можно указать один или несколько файлов, которые будут отображаться пользователю при выполнении man {имя пакета}.

требует внимания:

Файл man должен заканчиваться цифрой, а также может использовать суффикс .gz при сжатии. Этот номер указывает, в каком разделе man установлен файл;
Если имя файла man не начинается с имени модуля, во время установки перед ним будет стоять имя модуля.

Для приведенной выше конфигурации вы можете использовать следующую команду для выполнения документации представления:

man npm-access
man npm-audit

7. directories

Поле каталогов используется для указания каталога проекта. Модуль node.js реализован на основе модульной спецификации CommonJS и должен строго следовать спецификации CommonJS. В дополнение к файлу описания проекта пакета package.json каталог модуля также должен содержать следующие каталоги:

bin : каталог, в котором хранятся исполняемые двоичные файлы.
lib : каталог, в котором хранится код js.
doc : каталог, в котором хранится документация
test : каталог, в котором хранится код модульного тестового примера.
...

В фактическом каталоге проекта мы можем не называть в соответствии с этой спецификацией, тогда мы можем указать путь к файлу, соответствующий каждому каталогу в поле каталогов:

"directories": {
    "bin": "./bin",
    "lib": "./lib",
    "doc": "./doc",
    "test" "./test",
    "man": "./man"
},

Это свойство на самом деле не имеет практического значения и, конечно, не исключает, что в будущем найдутся более осмысленные применения.

6. Выпустить конфигурацию

Давайте взглянем на конфигурацию, связанную с публикацией пакета проекта npm.

1. private

Поле private не позволяет нам случайно опубликовать приватные библиотеки на сервере npm. Просто установите для этого поля значение true:

"private": true

2. preferGlobal

Поле PreferenceGlobal указывает, что если пользователь не устанавливает модуль как глобальный модуль, будет отображаться предупреждение, если установлено значение true. На самом деле это не мешает пользователям выполнять частичные установки, а только предлагает пользователям предотвратить недоразумения:

"preferGlobal": true

3. publishConfig

Конфигурация publishConfig вступит в силу, когда модуль будет опубликован, и используется для установки набора некоторых элементов конфигурации при публикации. Если вы не хотите, чтобы модуль помечался как актуальный по умолчанию или не хотите публиковать его в общедоступном репозитории, вы можете настроить тег или адрес репозитория здесь. Более подробная конфигурация может относиться кnpm-config.

Обычно publishConfig используется с private.Если вы хотите опубликовать модуль только в определенном репозитории npm, вы можете настроить его следующим образом:

"private": true,
"publishConfig": {
  "tag": "1.1.0",
  "registry": "https://registry.npmjs.org/",
  "access": "public"
}

4. os

Поле os позволяет нам указать, в какой операционной системе можно использовать пакет npm, а какую операционную систему использовать нельзя. Если мы хотим разработать пакеты npm, которые работают только в Linux, во избежание ненужных исключений рекомендуется, чтобы пользователи систем Windows не устанавливали его, тогда мы можем использовать конфигурацию ОС:

"os" ["linux"]   // 适用的操作系统
"os" ["!win32"]  // 禁用的操作系统

5. cpu

Эта конфигурация аналогична конфигурации ОС, и ЦП может более точно ограничивать среду установки пользователя:

"cpu" ["x64", "AMD64"]   // 适用的cpu
"cpu" ["!arm", "!mips"]  // 禁用的cpu

Как видите, разница между черным списком и белым списком заключается в том, что черному списку предшествует «!».

6. license

Поле лицензии используется для указания соглашения об открытом исходном коде программного обеспечения.Соглашение об открытом исходном коде выражает права, которые есть у других после получения кода, какие операции можно выполнять с кодом, а какие операции запрещены. Общие протоколы следующие:

Массачусетский технологический институт: Пока пользователи включают уведомление об авторских правах и уведомление о лицензии в свою копию проекта, они могут делать с вашим кодом все, что захотят, и вы не несете никакой ответственности.
Apache: аналогично MIT, но также включает положения, касающиеся лицензирования патентов, предоставляемые участниками пользователям.
GPL: Когда пользователь, изменяющий код проекта, повторно распространяет исходный или двоичный код, он должен опубликовать свои соответствующие модификации.

Поле можно объявить следующим образом:

"license": "MIT"

7. Сторонняя конфигурация

Файл package.json также может содержать конфигурацию для конкретной команды, такую как Babel, ESLint и т. д. Каждый из них имеет уникальные свойства, такие как eslintConfig, babel и т. д. Они зависят от команды, и как их использовать, можно найти в соответствующей документации команды/проекта. Давайте рассмотрим некоторые часто используемые сторонние элементы конфигурации.

1. typings

Поле typings используется для указания файла ввода TypeScript:

"typings": "types/index.d.ts",

Функция этого поля такая же, как у основной конфигурации.

2. eslintConfig

Конфигурацию eslint можно прописать в отдельном конфигурационном файле .eslintrc.json или в конфигурационном элементе eslintConfig файла package.json.

"eslintConfig": {
      "root": true,
      "env": {
        "node": true
      },
      "extends": [
        "plugin:vue/essential",
        "eslint:recommended"
      ],
      "rules": {},
      "parserOptions": {
        "parser": "babel-eslint"
     },
}

3. babel

Babel используется для указания конфигурации компиляции Babel.Код выглядит следующим образом:

"babel": {
	"presets": ["@babel/preset-env"],
	"plugins": [...]
}

4. unpkg

Используйте это поле, чтобы включить все файлы в npm для включения службы cdn, предоставляемой unpkg:

"unpkg": "dist/vue.js"

5. lint-staged

lint-staged — это инструмент, который запускает линтеры для временных файлов Git.После настройки каждый раз, когда файл модифицируется, может выполняться проверка всех файлов.Обычно используется вместе с gitHooks.

"lint-staged": {
	"*.js": [
  	"eslint --fix",
    "git add"
  ]
}

При использовании lint-staged для каждой фиксации проверяются только измененные в данный момент файлы.

6. gitHooks

gitHooks используются для определения хука, который выполняет проверки ESlint перед фиксацией. После выполнения команды lint файлы в промежуточной области автоматически восстанавливаются. Восстановленные файлы не будут храниться в промежуточной области, поэтому вам нужно использовать команду git add, чтобы повторно добавить восстановленные файлы в промежуточную область. После выполнения команды pre-commit, если ошибок нет, выполняется команда git commit:

"gitHooks": {
	"pre-commit": "lint-staged"
}

Вот, чтобы проверить код с приведенным выше lint-staged.

7. browserslist

Поле browserslist используется для указания поддерживаемых браузеров и версий. Он используется Babel, Autoprefixer и другими инструментами для добавления необходимых полифиллов и откатов в целевые браузеры. Например, значение поля в верхнем примере:

"browserslist": {
  "production": [
    ">0.2%",
    "not dead",
    "not op_mini all"
  ],
  "development": [
    "last 1 chrome version",
    "last 1 firefox version",
    "last 1 safari version"
  ]
}

Это указывает объект, который определяет требования к браузеру для рабочей среды и среды разработки. Вышеупомянутая разработка — это браузеры Chrome, Firefox и Safari, которые поддерживают последнюю версию в указанной среде разработки. Это свойство является инструментом конфигурации для совместного использования целевого браузера и версии узла между различными внешними инструментами и используется многими внешними инструментами, такими как Babel, Autoprefixer и т. д.

三连 .gif