Связанный фон:

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

1. Текущее состояние фронтенд-проектов

В группе фронтенда много проектов, но проверка качества кода непоследовательна. Например, такие проекты, как система xx и мобильный терминал, имеют простые конфигурации lintrc, но все они являются дублированными конфигурациями; такие проекты, как направление узла, почти просто настраиваются с помощью нескольких правил, а все проекты во внутренней системе yy не настраиваются. с обнаружением кода, в результате чего при CR необходимо неоднократно поднимать соответствующие вопросы стиля кода, кроме того, большинство вновь открываемых проектов вручную создают новые файлы и копируют конфигурацию, что избыточно и неэффективно.

2. Связанные проблемы и способы их решения

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

• Унифицируйте стиль кодирования членов команды, чтобы стиль кода был единым
• Улучшите читаемость кода, так как некоторые стилистические проблемы, такие как разрывы строк, могут затруднить чтение кода.
• Улучшите качество кода проекта и повысьте эффективность разработки.Lint может легко находить низкоуровневые и очевидные ошибки.Раннее обнаружение может уменьшить онлайн-проблемы, вызванные грамматическими проблемами, и сэкономить время, затрачиваемое на поиск и устранение неполадок.

1. Введение и значение инструментов, связанных с ворсом

1. JSLint

Ядром JSLint является синтаксический анализатор Пратта, реализованный методом приоритета оператора сверху вниз. В процессе непрерывной разработки, поскольку все правила в JSLint определяются личным стилем разработчика, слишком очевидно, что если вы хотите его использовать, то должны принять все определенные им правила, что приводит к рождению новых Инструменты линта/линтера.

2. JSHint

JSHint основан на JSLint, и его основная реализация по-прежнему основана на парсере Pratt, но он устраняет многие недостатки, выявленные JSLint. Более очевидно, что можно добавить настраиваемые правила, что описано в предложении в справочной статье: " Появление JSHint Почти неизбежно возникает непримиримый конфликт между постоянно растущими требованиями фронтенд-разработчиков к качеству кода и устаревшими и параноидальными инструментами».

3. ЗАО и ESLint

ESLint и JSCS были выпущены почти одновременно, и оба используют правила обработки AST и используют Esprima для анализа кода.Поскольку исходный код необходимо преобразовать в AST, скорость выполнения фактически теряется для JSHint; причина, по которой ESLint действительно популярен на самом деле С появлением ES6, ES6 добавил много новых грамматик, но некоторые конструктивные особенности самого JSHint несовместимы с новыми грамматиками, в то время как ESlint может не только расширять пользовательские правила, но и заменять парсер по умолчанию через babel-eslint из-за его высокой масштабируемости Синтаксис нового фреймворка также очень совместим, поэтому ESlint в итоге широко используется, а поскольку принципы реализации JSCS и ESLint схожи, поддерживать их не имеет смысла. ESLint объединены.

4. Prettier 

Prettier также является инструментом для проверки и оптимизации стиля кода, но у него мало настраиваемых правил.За исключением нескольких настраиваемых правил, ни одно из них нельзя изменить для достижения цели обязательного унифицированного стиля кода. Prettier отличается от ESlint. Как показано на рисунке ниже, он применим не только к коду JS, но и к другим распространенным языкам интерфейса, но его правила относятся только к стилю кода (Форматирование), а не к качеству кода (Код -качественный). Prettier можно использовать отдельно в проекте или в сочетании с ESlint.

2. Конфигурация проекта ESLint

1. Установите и используйте ESLint

1.1 Соответствующий код в файле открывает/закрывает соответствующее правило

Выполнение заказаnpm install eslint --save-devПосле установки вы можете напрямую открыть правила для соответствующих блоков кода в исходном коде проекта:

/* eslint console: "error" */ 
console.log('66666')

Соответствующие правила также можно отключить прямо в блоке кода:

1. 被包裹的代码块中取消eslint检查，也可以带上对应的规则表示仅禁用对应规则
/* eslint-disable */
alert(‘foo’); 
/* eslint-enable */

2. 针对某一行禁用eslint检查：
alert(‘foo’); // eslint-disable-line

// eslint-disable-next-line no-alert 
alert(‘foo’);

1.2 Включить/отключить правила в конфигурационных файлах

воплощать в жизньnpm install eslint --DПосле глобальной установки ESlint используйте командуeslint --initИнициализируйте файл конфигурации eslint.В процессе выполнения будут заданы некоторые вопросы по настройке.Вы можете выбрать в соответствии с вашими потребностями:

После завершения выбора будет сгенерирован файл инициализации .eslintrc следующим образом:

module.exports = {
  env: {
    browser: true,
    es6: true,
  },
  extends: [
    'plugin:vue/essential',
    'airbnb-base',
  ],
  globals: {
    Atomics: 'readonly',
    SharedArrayBuffer: 'readonly',
  },
  parserOptions: {
    ecmaVersion: 2018,
    sourceType: 'module',
  },
  plugins: [
    'vue',
  ],
  rules: {},
};

2. Введение в параметры конфигурации файла ESLint

Советы: рекомендуется смотреть непосредственно на английский перевод, так как некоторые китайские значения просто переведены неправильно.

Документация по параметрам конфигурации ESLint:ESL int.org/docs/user —…

В файле eslintrc очень много конфигурационных параметров, большинство из которых описаны в официальной документации, здесь же перечислены лишь некоторые из наиболее важных параметров при таком использовании:

• root: после установки значения true ESLint не будет искать файл для обнаружения (последующие два rcs опубликовали выводы теста)
• impliedStrict:ecmaFeaturesсерединаimpliedStrictПосле установки значения true вы можете整个项目中开启严格模式
• env: Указывает включенную среду, обычно включеннуюbrowserокружающая среда иnodeокружающая обстановка
• plugins: Имя соответствующего подключаемого модуля, которое может быть опущено напрямую.eslint-plugin-приставка
• extends: Совместно используемые пакеты конфигурации могут быть непосредственно представлены в расширениях, а префикс имени пакета также может быть опущен напрямую.eslint-config-, который также может напрямую указывать абсолютный или относительный путь к основному файлу конфигурации.
• rules: В параметрах rules можно задать множество встроенных правил eslint.В официальном документе перед правилами есть иконка патча.указывает, что правила могут быть автоматически восстановлены во время обнаружения, в противном случае будет сообщено об ошибке, и вам нужно вручную исправить ее самостоятельно. Все правила в атрибуте rules получают параметр со следующими значениями:

"off" 或 0：关闭规则
"warn" 或 1：开启规则，黄色警告 (不会导致程序退出)
"error" 或 2：开启规则，红色错误 (程序执行结果为0表示检测通过；执行结果为1表示有错误待修复)

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

3. Знакомство с параметрами командной строки

Документация по аргументам командной строки ESLint:ESL от /docs/user-a…

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

• Path-path --ignore:Чтобы не отставать от соответствующего имени файла, файл обнаруживается, когда eslint игнорируется при обнаружении этого файла.
• --исправить:После настройки этого параметра проблемы, которые могут быть исправлены автоматически, будут исправлены непосредственно при выполнении команды.Если вы не хотите автоматически исправлять во время выполнения, вы не можете настраивать его
• --rulesdir:Ссылка на путь к локальному правилу разработки

3. Пользовательский набор правил

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

1. Общая структура общего пакета конфигурации eslint-config-zly

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

1.1 Обратитесь к airbnb

Исходный код Airbnb: самостоятельно найдите исходный код на github.

Сначала я посмотрел на самый популярный airbnb в сообществе front-end.Airbnb в основном собирает две конфигурации в файле пакета.ESlint-config-airbnb в основном содержит некоторые конфигурации правил реакции, eslint-config-airbnb-base В основном базовая классификация конфигурации правил.

Поскольку eslint не предоставляет соответствующего шаблона для пакета конфигурации, после обращения к структуре каталогов airbnb вручную создайте файлы разных категорий и разделите некоторые встроенные правила в соответствии с различными функциональными блоками во введении модуля правил в eslint, а затем в .eslintrc.JS-файл импортируется по относительному пути extends. Однако, поскольку стек технологий, используемый самим проектом airbnb, относительно прост, выпуск двух пакетов таким образом не является проблемой. выпускать несколько пакетов.

1.2 Эталонный сплав.

исходный код:GitHub.com/alloy team/О…

Поскольку структура отдельного выпуска airbnb не очень подходит для нашего дизайна, мы взглянули на исходный код части из сплава. В сплаве некоторые правила, связанные со стилем, управляются Prettier.Внутренне некоторые правила в плагинах React/Vue/TypeScript перечислены в файлах base.js, vue.js, react.js, typescript.js в том же каталоге. документы, примеры, тесты, веб-сайты и т.д., каждому удобно обращаться к правилам сплава, и делать на этой основе свою персонализацию, и он использует высокую степень автоматизации travis-ci внутри для передачи всех процессы, которыми можно автоматически управлять в сценарии обработки, который разделяет и захватывает множество файлов конфигурации ESLint с помощью автоматических сценариев, каждое правило управляется в отдельном каталоге. Обратившись к структуре каталогов сплава, мы скорректировали структуру проекта eslint-config-zly, в основном поместив базовые правила и правила vue в один и тот же заданный каталог:

2. Аутсорсинг дизайна

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

2.1 Публикация нескольких пакетов и их совместное использование

Главное - отправить отдельный пакет для различных правил, и те, которые необходимо объединить, могут быть использованы вместе в расширении. Это в основном из-за слишком много управлений пакетов, а комбинированное использование не является прямым и удобным, поэтому оно заброшено.

extends: [airbnb/base, airbnb/base]

2.2 Выпуск нескольких пакетов, без комбинации:

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

参考： https://github.com/airbnb/javascript/blob/master/packages/eslint-config-airbnb-base/README.md

extends: airbnb/base
extends: airbnb/vue

一个项目中根据不同分类发布不同的包，如 airbnb 中项目 base 集模块单独发包 eslint-config-airbnb-base，
需要 base 的单独引入这个包即可

2.3 Публикуйте только один пакет и используйте его в комбинации

Как и в приведенном выше распределении, функции будут четко разделены по разным папкам. Например, base устанавливает только базовые правила, а vue устанавливает только правила vue. Если требуются оба правила, их можно использовать в сочетании, но поскольку бизнес-сторона мы хотим использовать, можем использовать его напрямую. Централизованный набор правил без ручного составления, поэтому эта схема немного не соответствует нашим ожиданиям.

参考： https://github.com/AlloyTeam/eslint-config-alloy/blob/HEAD/README.zh-CN.md

extends: alloy/base,
extends: alloy/vue,
extends: alloy/typescript

需要组合使用的话就 extends: [alloy/base, alloy/vue]

2.4 Отправляйте только одну посылку, комбинированное использование запрещено.

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

extends: zly/vue
extends: zly/react
extends: zly/tina
extends: zly/node

vue 的项目就单独引入 zly 包的 vue 集， node的项目就单独引入 zly 包的 node 集

3. Наборы правил

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

- 'best-practices.js'
- 'custom.js'
- 'errors.js'
- 'es6.js'
- 'import.js'
- 'tyle.js'
- 'variables.js'

Наконец, в файле _base index.js представляет указанный выше файл вместе с пакетом airbnb-base как расширения:

Советы: При разборе набора узлов обнаруживается, что проект узла нужно разрабатывать в строгом режиме.ImpliedStrict в ecmaFeatures установлен в true, то есть проект находится в строгом режиме, и писать ' use strict' Сначала я просто хотел прописать эту конфигурацию в The node set, а после окончательного обсуждения ее все-таки поместить в базовый набор, чтобы убедиться, что все используемые проекты находятся в строгом режиме.

module.exports = {
  parserOptions: {
    ecmaFeatures: {
      impliedStrict: true,
    }
  },
  extends: [
    'airbnb-base',
    join(__dirname, './rules/best-practices'),
    join(__dirname, './rules/errors'),
    join(__dirname, './rules/es6'),
    join(__dirname, './rules/import'),
    join(__dirname, './rules/style'),
    join(__dirname, './rules/variables'),
    join(__dirname, './rules/custom'),
  ],
}

3.2 vue набор

Набор правил vue в основном представляет рекомендованный vue3 набор _base в eslint-plugin-vue, а затем настраивает его для определенных правил:

module.exports = {
  env: {
    browser: true,
  },
  extends: [
    'plugin:vue/vue3-recommended',
    join(__dirname, '../_base/index'),
    join(__dirname, './rules/vue'),
  ],
  parserOptions: {
    parser: 'babel-eslint',
  },
  plugins: ['vue'],
}

3.3 набор тины

Правила tina в основном предназначены для небольших программных проектов, и они также используют синтаксис vue. Здесь я обсудил, следует ли вводить набор правил vue или напрямую вводить eslint-plugin-vue. Наконец, я решил напрямую ввести набор vue и вручную обновить тину на ненужные правила.Централизованное отключение:

module.exports = {
  globals: {
    App: true,
    Page: true,
    wx: true,
    getApp: true,
    getPage: true,
    getCurrentPages: true,
  },
  extends: [
    join(__dirname, '../vue/index'),
    join(__dirname, './rules/tina'),
  ],
  parserOptions: {
    parser: 'babel-eslint',
  },
}

3.4 Набор узлов

В процессе формулировки набора узлов я читал eslint-config-node, eslint-config-egg, eslint-plugin-eggache и eslint-plugin-node После сравнения обнаружил, что правила узла, сформулированные в eslint-plugin -node plugin являются самыми чистыми.Кроме того, eslint-plugin-node в сообществе использует больше решений и предоставляет больше решений, поэтому после многочисленных исследований было окончательно принято решение eslint-plugin-node. Набор узлов использует рекомендованный в eslint-plugin-node, затем вводит набор _base и, наконец, выполняет специальную обработку в rules/node/index.js для конкретных правил узла.

module.exports = {
  env: {
    node: true,
  },
  extends: [
    'plugin:node/recommended',
    join(__dirname, '../_base/index'),
    join(__dirname, './rules/node')
  ],
  plugins: ['node'],
}

Для приведенных выше наборов правил, за исключением _base, порядок других расширений таков: сначала вводить правила сторонних подключаемых модулей, затем правила _base и, наконец, вводить файлы, измененные их собственными специфическими правилами.

4. Пользовательские плагины

Пользовательские правила ELSint и анализ исходного кодаНаггетс.Талант/редактор/Конечно Афан…

После настройки структуры проекта, внешнего дизайна и набора правил, когда я захотел интегрировать пользовательское правило Haoge «_.get запрещает третий параметр», я обнаружил, что пакет пользовательской конфигурации eslint не может интегрировать пользовательские правила.只有自定义插件才可以集成自定义规则, поэтому весь проект переходит от конфигурации к плагину.

1. Используйте шаблон для инициализации конфигурации

Генератор Yeoman-eslint:yeoman.io/authoring/

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

npm i -g yo
npm i -g generator-eslint
// 创建一个plugin
yo eslint:plugin
// 创建一个规则
yo eslint:rule

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

• В папке rules хранится каждый файл правил
• Папка с тестами содержит файлы модульных тестов.
• package.json — это файл описания пакета npm плагина ESLint. Атрибут name — это имя плагина ESLint. Правило именования: eslint-plugin-*

2. Интегрируйте пользовательские правила

Конфигурация в папке lib децентрализует классификацию набора настраиваемых правил, определенную ранее, папка rules децентрализует соответствующую классификацию настраиваемых правил, а настраиваемые правила, написанные в следующей статье для _.get(), запрещающие третий параметр, помещаются в под lodash -get.js в правилах и импортированный в index.js:

3. Локальное тестирование

Если ваш пакет npm еще не выпущен и нуждается в локальной отладке, вы можете использовать ссылку npm для локальной отладки. Выполните команду npm link в проекте eslint-plugin, вы можете использовать команду eslint-plugin глобально, а затем вы можете выполнить npm link eslint-plugin в своем тестовом проекте, чтобы импортировать тест. Выполнение команды npm link в папке пакета npm создаст символическую ссылку между глобальной папкой {prefix}/lib/node_modules/ и папкой пакета, в которой вы выполнили ссылку npm.

Примечание: имя-пакета — это имя в package.json, а не имя папки.

5. Оптимизация обнаружения отправки кода

1. git hooks

Git-хуки — это хуки в процессе выполнения git, которые могут запускать пользовательские скрипты. Под каждым проектом, содержащим репозиторий, есть файл .git, и каждый файл .git содержит файл хуков, вы можете использовать имя хука в этой папке.创建相应的钩子文件, когда git что-то делает相应的钩子文件就会被执行.

На следующем рисунке показан кейс-скрипт каждого хука.Вы можете удалить образец и напрямую написать шелл-скрипт для выполнения:

Крючки, которые мы обычно используем:

• предварительная фиксация:Он вызывается при выполнении git commit. Он выполняется перед отправкой коммита. Он может проверять код, который нужно отправить. Если результат не равен 0 и выйти, отправка будет прервана.
• сообщение фиксации:Вызываемая с помощью git commit или git merge, при выходе с ненулевым кодом состояния операция будет прервана, в основном для обнаружения формата комментария представленного кода.

Вопрос. Можно ли загрузить соответствующую конфигурацию файла ловушки в файле .git напрямую в удаленное хранилище, чтобы другие могли извлечь ее для достижения эффекта совместного использования конфигурации?

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

2. husky

husky — незаменимый инструмент для фронтенд-инжиниринга.Поскольку напрямую модифицировать файл .git/hooks неудобно, использование husky позволяет нам легко добавлять git-хуки в проект.

2.1 библиотека предварительной фиксации

В начале проекта библиотека предварительной фиксации обычно настраивается на роль обнаружения перед фиксацией.npm install pre-commit --save-devПосле загрузки и установки нажмите следующую конфигурацию в проекте, и он будет выполнен, прежде чем мы совершаем.

{ 
  "scripts": { 
    "lint": "eslint . --fix", 
  }, 
  "pre-commit" : ["lint"], 
}

2.2 Husky + крючок Pre-Commit

В дополнение к использованию только библиотеки pre-commit для обнаружения кода перед фиксацией, наиболее часто используемым в настоящее время является использование husky,npm install husky --save-devПосле установки настройте его в package.json, и вы можете вместе использовать хук pre-commit, чтобы при отправке коммита выполнялся скрипт npm run lint для проверки всего файла проекта. Если только текущую конфигурацию.

Примечание. Если проект был предварительно обнаружен с помощью библиотеки предварительной фиксации ранее, и вы хотите позже изменить режим обнаружения хука husky + pre-commit, вам необходимо удалить node_modules, а затем установить его, чтобы он вступил в силу. , потому что библиотека предварительной фиксации все еще существует, и они будут конфликтовать и приведут к сбою выполнения husky.

{ 
  "husky": { 
    "hooks": { 
      "pre-commit": "npm run lint", // 在commit之前先执行npm run lint命令 
    } 
  } 
  "scripts": { 
    "lint": "eslint . --ext .js,.vue", 
  } 
}

3. lint-staged

Конфигурация Husky может легко реализовать обнаружение кода перед фиксацией, но использование обнаружения напрямую также принесет много недостатков, таких как обнаружение всех файлов проекта при каждой отправке. Если мы хотим обнаружить только отправленный код, мы можем использовать lint-staged, Lint-staged читает только файлы в области подготовки и запускает настроенный скрипт, избегая воздействия на код, который не был отправлен в область подготовки. . Файл фильтра lint-staged принимает синтаксис glob, который можно использовать с хаски, хаски триггеры lint-staged, а затем lint-staged выполняет сценарий.После настройки это может не только уменьшить проблему, заключающуюся в том, что eslint потребляет слишком много времени для полного обнаружение, но и сократить время на устранение проблем!

// package.json 文件

  "husky": {
    "hooks": {
      "pre-commit": "lint-staged",
    }
  },
  "lint-staged": {
    "*.vue": [
      "eslint --cache --fix"
    ],
    "*.js": [
      "eslint --cache --fix"
    ]
  },

3.1 Две конфигурации .eslintrc.js

Есть некоторые проекты, которые не являются отдельным проектом vue или проектом узла. Как и в системе xx, узел используется в качестве промежуточного уровня. В настоящее время в проекте будет две среды. Чтобы проверить с помощью разных наборов правил в папках разных сред, здесь мы собираемся настроить два файла .eslintrc.Основная конфигурация выглядит следующим образом:

// package.json 文件

"scripts": {
  "lint": "npm run lint-web && npm run lint-node",
  "lint-web": "eslint . -c ./.eslintrc-web.js --ext .js,.vue --ignore-pattern server/ --cache --fix",
  "lint-node": "eslint server/ -c ./.eslintrc-node.js --ext .js --cache --fix",
}    

// .eslintrc-web.js 文件

module.exports = {
  root: true,
  plugins: [
    '@zly'
  ],
  extends: [
    'plugin:@zly/vue',
  ],
}

// .eslintrc-node.js 文件

module.exports = {
  root: true,
  plugins: [
    '@zly'
  ],
  extends: [
    'plugin:@zly/node',
  ],
}

После завершения настройки операция может нормально выдать ошибку, но функция автоматического автоисправления полностью недействительна. Последующие выводы могут быть вызваны тем, что мы изменили .eslintrc.js на .eslintrc-node.js и .eslintrc-web.js.После изменения IDE не может динамически распознавать конфигурацию eslint. Однако его можно настроить вручную в редакторе, но настраивать компилятор вручную для всех действительно хлопотно, поэтому мы подумали о предыдущем параметре root.

3.2 корневой тест

Когда я вводил корневой параметр ранее, я смотрел официальные документы и связанные с ними переводы в Интернете.Я всегда чувствовал, что разные переводы разные, и я сам неоднозначно относился к этому понятию, поэтому я провел эксперимент с корневым тестом. В основном создайте новый файл .eslintrc.js в корневом каталоге проекта eslint-root-test и создайте новый файл .eslintrc.js в папке сервера корневого каталога.На случай, если корневая конфигурация в два .eslintrc.js не проходят Проведите тест, и результаты теста будут следующими:

В соответствии с приведенными выше результатами тестирования было обнаружено, что root может просто удовлетворить нашу потребность в двух копиях rc, поэтому для интеллектуальной системы файл .eslintrc.js устанавливается в следующем каталоге, файл .eslintrc.js устанавливается в файле сервера и установлены две копии rc.Корень файла установлен в значение true, а окончательная конфигурация такова:

// package.json 文件

  "husky": {
    "hooks": {
      "pre-commit": "lint-staged",
      "commit-msg": "commitlint -e $HUSKY_GIT_PARAMS"
    }
  },
  "lint-staged": {
    "*.vue": [
      "stylelint --config /.stylelintrc.short.js",
      "stylelint --config /.stylelintrc.js --fix",
      "eslint --cache --fix"
    ],
    "*.css": [
      "stylelint --config /.stylelintrc.short.js",
      "stylelint --config /.stylelintrc.js --fix"
    ],
    "server/**/*.js": [
      "eslint -c ./server/.eslintrc.js --cache --fix"
    ],
    "!(server)/**/*.js": [
      "eslint --cache --fix"
    ]
  },
    
  "scripts": {
    "lint": "npm run lint-web && npm run lint-node",
    "lint-web": "eslint . --ext .js,.vue --ignore-pattern server/ --cache --fix",
    "lint-node": "eslint server/ -c ./server/.eslintrc.js --ext .js --cache --fix",
  },

Выполните npm run lint, чтобы полностью запустить обнаружение всех файлов. Если обнаружение выполняется отдельно, npm run lint-web и npm run lint-node могут выполняться отдельно. Конфигурация в lint-staged также выполняет обнаружение временных файлов для сервера файлы и несерверные файлы.

4. Когда package.json отличается от версии зависимости в node_modules

библиотека проверки зависимостей:Уууу, эта лошадь plus.com/package/cars…

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

Вопрос один:

В: Если нам нужно каждый раз обновлять наши собственные зависимости приватных пакетов npm в package.json, но локальная версия по-прежнему остается старой, как мы можем указать на несоответствие между частной удаленной версией npm и локальной версией?

Решение первое:

A: Я искал и не нашел особо подходящего решения.

Решение второе:

A: Я не нашел очень подходящего способа сделать такую ​​подсказку для пакета, выпущенного мной, но я нашел его в процессе поиска.check-dependenciesЭта библиотека, эта библиотека не обнаружит определенную зависимость, это удаленное и локальное сравнение всех зависимостей в package.json, если одна из них не синхронизирована, она выдаст подсказку.

4.1 скриптовый хук npm

Скрипт npm — это несколько пользовательских скриптов, записанных в поле скриптов в package.json.Используя пользовательские скрипты, пользователи могут записывать в package.json некоторые командные строки, обычно используемые в проектах, без необходимости вводить их каждый раз. В скриптах npm есть два хука, pre и post, и пользовательские команды скрипта также могут добавлять pre и post хуки. Например, хуки команды сценария dev — predev и postdev.Когда пользователь запускает npm run dev, он автоматически выполняется в следующем порядке:

npm run predev && npm run dev && npm run postdev

4.2 check-dependencies

После скачивания и установки чек-зависимостей планирую выполнить нодовый скрипт check.js в хуке predev.При выполнении npm run dev команды в predev будут выполняться заранее.Если обнаружится, что зависимости с обеих сторон отличается, ошибка будет выдана и прервана.Когда две стороны согласованы, тогда он работает нормально:

// package.json 文件

"scripts": {
  "predev": "node check.js"
}

const output = require('check-dependencies')
  .sync({
    verbose: true, 
  })

if (output.status === 1) {
  throw new Error('本地依赖与package.json中不同步，请先npm install再执行')
}

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

// package.json 文件

"scripts": {
  "predev": "check-dependencies"
}

VI. Последующее развитие

1. Ежедневное обслуживание

В настоящее время большинство проектов были заменены, и тест проходит нормально.Чтобы получить доступ к инструменту обнаружения новых проектов, вам нужно только установить пакет npm в .eslintrc.js Может вступить в силу средняя конфигурация, она проста и удобна, нужно лишь унифицировать некоторые правила в дальнейшем.

2. Незавершенные элементы

На самом деле, я обнаружил много проблем во время теста. Например, я привык использовать webstrom в начале, но при тестировании действительно было слишком много проблем. Я следовал принципу одной переменной и использовал vscode для тестирования, и я искал много проблем.Нигде нет решения,основные проблемы следующие:

• С той же конфигурацией vscode может автоматически исправить нормально, но автоматическое исправление eslint не работает в webstrom
• При отправке кода в исходное дерево обнаружение eslint обходится по неизвестным причинам.

3. Ссылки в этой статье

Отладка инструмента командной строки:сегмент fault.com/ah/119000001…

Практика применения ESLint в средних и больших командах:Специальности.Meituan.com/2019/08/01/…