1. Первоначальное намерение представить инструмент сканирования

1.1 Воздействие на болевые точки

В настоящее время при разборе фронтенд-приложений я обнаружил множество несоответствий в коде, в том числе простые проблемы с js и проблемы с форматированием кода, из-за которых читабельность кода снижалась.Кроме того, разные исторические коды тоже "разные стили". мир» люди поддерживают вместе, неизбежно есть «жареное мясо в кантонском стиле, тяньцзиньские губули» различные вкусы, и еще более неизбежный «благоухающий запах», эти ситуации серьезно влияют на качество приложения. Большинство участников разработки приложений не имеют опыта в разработке интерфейса из-за отсутствия опыта в разработке интерфейса, и многие системы знаний по интерфейсу постепенно накапливаются в процессе разработки.Существуют плагины, такие как плагины для сканирования спецификаций разработки Java. и аналогичные внешние плагины для проверки качества кода для контроля. После проверки данных,eslint+husky+prettier+lint-stagedСпособ улучшить качество внешнего интерфейса в определенной степени, причина принятия этого метода, болевые точки заключаются в следующем:

Спецификацию кода трудно реализовать: Спецификация кода эквивалентна контракту команды и даже всей технической команды компании.В то же время эти спецификации являются драгоценным богатством, оставленным крещением многих старших мастеров через проект, что может сократить множество обходных путей. в развитии.Однако перед лицом развития Нынешняя ситуация, с которой часто сталкиваются нормы, заключается в том, что их трудно реализовать, и это всегда «удаление восточной стены, чтобы составить западную стену». В конечном итоге необходимы инструменты принудительно гарантировать, что код должен быть просканирован спецификацией разработки кода;
Использование некачественного кода в онлайн-приложениях: В реальной ситуации разработки разработчики могут просто выполнить операцию git push, чтобы перенести локальный код в удаленную ветку.Если качество кода низкое, легко похоронить скрытые опасности для качества онлайн-приложения. для CR при слиянии, Таким образом, ссылка обратной связи слишком длинная. Когда лучший способ совершить локальную фиксацию — это, по крайней мере, убедиться, что текущий код может соответствовать спецификациям разработки, установленным командой, если он не проходит, фиксация не получится, что может гарантировать качество кода из самого источника;
Формат кода трудно унифицировать: В соответствии с текущей ситуацией, члены команды разработчиков имеют очень разные форматы кода.Некоторым людям даже нравится использовать двойные кавычки для строк, а некоторым людям нравится использовать одинарные кавычки.Если проблемы с форматированием кода неоднородны, они всегда чувствуют, что друг друга смотреть на чужой код всегда странно, и даже формат кода неупорядочен, что серьезно влияет на читабельность кода и несомненно увеличивает затраты на общение внутри команды.Для такой ситуации нужен инструмент обеспечить единообразие формата кода внутри команды;
Культуру качества кода трудно внедрить: Внедряя инструменты качества кода, вы всегда можете ограничивать собственное качество кода в процессе разработки, постепенно культивировать собственную концепцию разработки «чистоты» по качеству кода, и в то же время она станет отправной точкой для команды и даже себе внедрить культуру качества.

Для вышеуказанных болевых точек примитеeslint+husky+prettier+lint-stagedЭти инструменты позволяют эффективно решить вышеуказанные проблемы, а процесс выполнения и принципы приведены ниже (В то же время еще один отсыл к культуре качества кода — CR также можно найти в «Год на Али, думая о код-ревью»).

1.2 Достичь эффекта

Чтобы предотвратить проблемы до того, как они возникнут, и предотвратить перенос потенциально проблемного кода в онлайн-среду, лучше всего сканировать потенциальные ошибки при локальной отправке кода и принудительно изменять его перед отправкой, чтобы он не код проблемы в онлайн может гарантировать, что в онлайн-коде не будет хотя бы низкоуровневых программных ошибок. Для такого запроса,husky、lint-staged、eslint以及prettierПлагины для достижения конкретных эффектов заключаются в следующем:

Как показано на рисунке выше, при попытке зафиксировать код его не удается успешно отправить из-за ошибок сканирования, и перед фиксацией его необходимо успешно изменить.

1.3 Файлы конфигурации

во фронтенд приложенияхpackage.jsonДобавил следующие файлы в:

{
  "scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "src/**/*.js": [
      "eslint --fix --ext .js",
      "prettier --write",
      "git add"
    ]
  },
  "devDependencies": {
    "eslint": "^5.0.0",
    "eslint-config-ali": "^2.0.1",
    "eslint-plugin-import": "^2.6.0",
    "eslint-plugin-react": "^7.1.0",
    "husky": "^0.14.2",
    "babel-eslint": "^8.1.1",
    "lint-staged": "^4.0.0",
    "prettier":"^1.16.4",
    "eslint-plugin-prettier":"^3.0.1",
    "eslint-config-prettier":"^4.0.0"
  },
}

Увеличивать.eslintrc.jsПравила сканирования:

module.exports = {
  "extends": ["eslint-config-ali","prettier", "plugin:prettier/recommended"],
  "parser": "babel-eslint",
  "rules": {
    "prettier/prettier": "error",
    "strict": "off",
    "no-console": "off",
    "import/no-dynamic-require": "off",
    "global-require": "off",
    "require-yield": "off",
  },
  "plugins": ["prettier"],
  "globals": {
    "React": "readable"
  }
};

Увеличивать.prettierrc.jsфайл для форматирования кода после прохождения сканирования (этот шаг необязателен, если не вводить красивее, можно удалить соответствующую конфигурацию в package и eslintrc соответственно)

module.exports = {
  printWidth: 80,
  semi: true,
  singleQuote: true,
  trailingComma: 'none',
  bracketSpacing: true,
  jsxBracketSameLine: false,
  arrowParens: 'avoid',
  requirePragma: false,
  proseWrap: 'preserve'
};

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

2. Принцип реализации

2.1 Процесс выполнения

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

Отправляемый код добавляется в тестовую область командой git add;
Выполнить git-коммит;
Вызывается функция ловушки, зарегистрированная husky в git pre-commit, и выполняется lint-staged;
lint-staged получает все отправленные файлы и по очереди выполняет письменные задачи (ESLint и Prettier);
Если есть ошибка (не прохождение проверки ESlint), остановите задачу, заодно распечатайте сообщение об ошибке, дождитесь исправления и затем выполните коммит;
Успешная фиксация, отправка на удаленный сервер

В вышеописанном процессе есть несколько основных моментов:

Husky регистрирует функцию ловушки git, чтобы гарантировать, что действие сканирования кода вызывается, когда git выполняет коммит;
eslint выполняет сканирование по настроенным правилам;
Lint-staged гарантирует, что сканируются только те файлы, которые в настоящее время добавлены в область git stage.Причина этого в том, чтоЕсли сканируются файлы всего проекта, а в предыдущем фронтенд-проекте не уделялось внимания обнаружению правил кода, велика вероятность, что возникнут сотни ошибок., в основном с разбитым сердцем. Таким образом, для достижения цели своевременного стоп-лосса обнаруживаются только добавленные в данный момент файлы, а исторический код может быть вырезан в новую ветку для исправления, а затем объединен.

2.2 Описание плагина

В процессе выполнения в версии 2.1 в основном используются такие плагины, как eslint и lint-staged, описание которых приведено ниже.

2.2.1 eslint

Что такое линт?

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

Зачем вводить эслинт?

По моему мнению, введение eslint может иметь следующие преимущества:

Поскольку это инструмент сканирования кода, он, естественно, может обеспечить реализацию спецификаций разработки.Например, подключаемый модуль сканирования спецификаций разработки Java, eslint является таким инструментом для внешнего интерфейса.Настроив спецификации кода, указанный код спецификации гарантированно выполняются. Кодовые спецификации некоторых распространенных производителей:Внешний вид Али,Команда Goose FactoryЖдать;
Для обеспечения онлайн-качества приложения этот пункт не нужно повторять.В сочетании с использованием других инструментов код, не соответствующий спецификации кода, не может быть отправлен в удаленную ветку;
Более высокая удобочитаемость, eslint будет сканировать качество кода и, как правило, используется в сочетании с более красивым кодом, код может быть отформатирован после прохождения спецификации кода, что может обеспечить читаемость кода;
Избегайте ошибок низкого уровня,eslint --fixНекоторые низкоуровневые проблемы с кодом могут быть исправлены согласно спецификации.

Как пользоваться эслинтом?

Как указано в начале статьиpackage.jsonВы можете настроить его.Информацию об использовании lint см.официальная документация, спецификация кода настройки eslint также приведена в статьеeslintrc.jsКак указано в , так называемая спецификация кода, естественно, указывается в соответствии с текущим статусом команды, и в настоящее время мы используем спецификацию внешнего интерфейса Ali.eslint-config-ali, конечно, можно и по текущей ситуации сформулировать "по местным условиям". Кроме того, следует указать, что вeslintrc.jsнастраивается в конфигурационном файлеglobalsПеременная:

"globals": {
  "React": "readable"
}

Это связано с тем, что среда React, используемая во внешнем интерфейсе, eslint будет сканировать React и другие переменные и сообщать об этом.no-undefinedошибка, вам нужно установить ее как глобальную переменную, чтобы избежать сканирования. Это настраивается в дизайне правил eslint, вrulesЕго можно задать в свойствах , а конкретное правило eslint можно увидетьофициальная документация, который отмечен галочкойeslint:recommendedРекомендуемые правила использования.

2.2.2 husky

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

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

что такое гит хук

Хук git можно понять как при выполнении, напримерgit add、git commitВы можете просмотреть обратный вызов при ожидании операции git.gitКаталог hooks под файлом содержит несколько примеров скриптов операций, связанных с git. С помощью git hook сканирование кода может быть запущено при локальном коммите, чтобы обеспечить качество локального кода. О git hook можетсм. эту статью.

2.2.3 lint-staged

Использование eslint и husky может гарантировать качество кода, но оно должно столкнуться с проблемой в реальном проектировании. На самом деле в приложении обычно участвует несколько участников разработки, а в жизненном цикле приложения также задействованы кадровые изменения, а это означает, что приложение совместно поддерживается людьми «со всего мира», и неизбежно будет « Жареное мясо по-кантонски». , Тяньцзинь Губули «все виды вкусов, и более неизбежно, что есть «запахи».

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

После изменения файла A появились ошибки файлов B, C, D и других. Для таких болевых точек,То есть каждый раз сканировать только измененный в данный момент файл, то есть сканировать файлы, добавленные в рабочую область с помощью git add, и завершать проверку инкрементного кода.. Как этого добиться? Здесь нужно использоватьlint-stagedИнструмент для идентификации файлов, добавляемых в рабочую область. О lint-stage canсм. официальную документацию, сейчас посмотрюpackage.jsonФайл может понять, что это значит:

"scripts": {
  "precommit": "lint-staged"
},
"lint-staged": {
  "src/**/*.js": [
    "eslint --fix --ext .js",
    "prettier --write",
    "git add"
  ]
},

Когда выполняется git commit, запускается git hook для выполнения предварительной фиксации, а сценарий предварительной фиксации ссылается на конфигурацию lint-staged, чтобы указать, что сканируются только те файлы, которые git добавляет в область рабочей области.В частности, lint-staged выполняет три вещи. : 1. Выполните операцию eslint --fix, просканируйте и устраните проблемы, которые можно исправить с помощью инструмента; 2. Выполните более красивый скрипт, который форматирует код, как описано ниже; 3. После выполнения двух вышеуказанных задач код повторно добавляется.

2.2.4 prettier

Инструмент Prettier в основном используется для унификации формата кода, и eslint также выполняет определенную проверку формата кода, но в основном он используется для сканирования спецификации кода, а инструмент prettier специально используется для форматирования кода. два инструмента Каждый выполняет свои обязанности и сопровождает качество кода. Его основной принцип заключается вСравните код до форматирования с кодом после форматирования, если окажется, что он отличается, prettier пометит его и исправит в соответствии с заданной спецификацией форматирования.. На следующем рисунке показана способность красивее (поддержка идет из сети)

Видно, что красивее можно отформатировать код, чтобы обеспечить читабельность кода. perttier может поддерживать различные форматы, такие как JSX, HTML и т. д., вы можете просмотреть подробностиофициальная документация, стандарт форматирования кода может быть определен совместно в соответствии с текущей ситуацией в команде.

Плагины для использования с eslint

Для работы с eslint необходимо установить два плагинаeslint-plugin-prettier和eslint-config-prettier, что необходимо пояснить, чтоeslint-config-prettierФункция плагина, этот плагин заключается в том, что правила eslint и правила prettier конфликтуют (в основном ненужные конфликты), например, eslint ограничивает необходимость одинарных кавычек, а prettier также ограничивает необходимость одинарных кавычки, то если вы используете eslint, чтобы водить красивее. Если вы придете, чтобы проверить код, вам будет предложено два вида ошибок, хотя все они указывают на одну и ту же ошибку кода, этот плагин отключит дополнительные отчеты об ошибках. оeslint-config-prettierмогу это увидетьофициальная документация.

3. Плагины IDE используются вместе

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

Как установить плагины eslint

Как показано на рисунке, вам нужно только указать файл конфигурации eslint в webstorm.

Как установить красивый плагин

Как показано на рисунке, webstorm имеет встроенную функцию prettier, просто убедитесь, что в текущем проекте установлен пакет prettier.

4. Пишите в конце

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

5. References

Обнаружение хаски и предварительная фиксация перед git фиксацией

Используйте ESlint, lint-staged для полуавтоматического улучшения качества кода проекта.

Создавайте супергладкие рабочие процессы проверки кода с помощью husky и lint-staged.

Сочетание фронтенд-разработки с использованием eslint и prettier для проверки и форматирования кода

Руководство по настройке AlloyTeam ESLint

Используйте ESLint+Prettier для унификации стиля внешнего кода.

Управляйте проектами с помощью eslint + prettier + pre-commit (React)

Конфигурация React-native ESLint, Prettier и Pre-commit Hook

Управляйте проектами с помощью eslint + prettier + pre-commit (React)

Введение и основы использования Prettier