Как четко оценить негласные правила команды

внешний интерфейс WeChat JavaScript ESLint

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

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

  • Согласованный путь к модулю, метод именования и другие спецификации не соблюдаются, и разработка проекта представляет собой беспорядок.
  • Чтобы сделать то же самое, в некоторых местах используются сторонние библиотеки, в некоторых местах используются внутренние библиотеки, а в некоторых местах они переписываются сами.
  • Старая грамматика и новая грамматика сосуществуют. Например способ импорта библиотеки, есть ESM/CommonJS/UMD и так далее.
  • ...

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

  • Если новые одноклассники не знают, что мы привыкли импортироватьlodash/xxxчтобы уменьшить размер пакета, то он может импортировать lodash полностью.
  • Если новый студент не знает, что мы инкапсулировали базовую библиотеку для обработки общих бизнес-требований, таких как запросы и сериализация, он может установить стороннюю библиотеку или даже заново изобрести велосипед.
  • Если новый студент не знает, что наши бизнес-компоненты наследуются от общего базового класса, он может начать новую версию, которую ему проще всего понять.
  • ...

Проблема непротиворечивости на этом уровне выходит за рамки использования пробелов или табуляции или добавления точки с запятой в конце строк Существующие на рынке инструменты проверки стиля кода «не так широки». Конечно, этот уровень проблем действительно может быть решен с помощью проверки кода, но ручная проверка не может быть отброшена в сторону в каждой команде, которая рекламирует Agile и Moving Fast. Итак, есть ли у нас более эффективные средства для установления этих неявных «негласных правил»? Здесь мы пытаемся дать ответ:Напишите свой собственный бизнес-плагин lint.

В 2018 году ESLint в основном является важной зависимостью в надежной структуре внешнего интерфейса. Но в большинстве случаев мы используем готовый кодстильТехнические характеристики. Но на самом деле ESLint можно использовать не только для обнаружения стилистических проблем, таких как пробелы и разрывы строк.В сочетании со спецификациями по развитию бизнеса вы обнаружите, что он также имеет большой потенциал. А процесс написания плагина ESLint с нуля на самом деле не сложный, давайте посмотрим, как это попрактиковаться:

Конфигурация среды

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

npm install -g yo generator-eslint

Мы можем создать свой собственный плагин:

mkdir eslint-plugin-demo
cd eslint-plugin-demo

yo eslint:plugin

? What is your name? ...
? What is the plugin ID? demo
? Type a short description of this plugin: ...
? Does this plugin contain custom ESLint rules? Yes
? Does this plugin contain one or more processors? No

npm install

Инициализируйте плагин, просто иcreate-react-appТак же легко, правда?

Создать правило

Теперь пришло время создать наше первое правило Lint! Например, автору, который любит пробелы, не нравятся такие комментарии в коде:

// 获取abc数据2次

Соглашение о наборе текста на китайском языке в Интернете на самом деле такое:

// 获取 abc 数据 2 次

Но не все настаивают на ручной вставке пробелов в чате WeChat, как автор, и принудительное изменение чужих комментариев в записи коммита также вызывает у других дискомфорт. Итак, как нам обновить это соглашение до правил ESLint? Нам нужно немного понять, как работает ESLint.

Использование ESLintEspreeЭтот парсер JavaScript для анализа исходного кода вашего проекта. Parser разберет строку исходного кода в абстрактное синтаксическое дерево (AST).Для каждого узла в дереве ESLint найдет, существует ли соответствующее правило, и, если оно совпадает, рассчитает, выполняется ли правило. И как выглядит АСТ? Например, линия// hello worldФайл кода JS, формат AST выглядит следующим образом:

{
  "type": "Program",
  "start": 14,
  "end": 14,
  "body": [],
  "innerComments": [
    {
      "type": "Line",
      "value": " hello world",
      "start": 0,
      "end": 14
      "range": [
        0,
        12
      ]
    }
  ],
  "//": "......"
}

Основываясь на этой структуре данных, если мы хотим добавить правила ко всем операторам объявления переменных, наши правила плагина будут выглядеть так:

module.exports = function (context) {
  return {
    'VariableDeclaration' (node) {
      // 在这里搞事情
      // ...
    }
  }
}

этоVariableDeclarationОткуда это? Настало время показать свое знакомство с ES Spec в качестве старшего фронтенда! На самом деле каждому оператору в JavaScript соответствует определенный в спецификации тип, и мы можем написать правила его проверки по имени типа. Если мы хотим проверить аннотацию, то заменим имя в приведенном выше примере наCommentВот и все. Разве это не интуитивно?

Вышеуказанный способ можно понять как очень классический режим посетителей. Хотя удобно писать правила, декларивно, он также имеет проблему полной прозрачности между соседними узлами, которая неудобна для некоторых сложных операций. Таким образом, вы также можете использовать некоторые из более процедурных API для оказания помощи в написании правил:

module.exports = {
  create: function (context) {
    const sourceCode = context.getSourceCode()

    return {
      // Program 相当于 AST 根节点
      Program () {
        const comments = sourceCode.getAllComments()
        comments.forEach(node => {
          if (/* 满足校验规则 */) {
            context.report(node, 'Something WRONG!')
          }
        })
      }
    }
  }
}

Для нашей текущей необходимости обнаруживать пробелы, готовая зависимостьpangu.js. Мы можем убедиться в этом, вызвав API форматирования pangu в комментарии выше. Однако при написании собственных подключаемых модулей конкретные бизнес-правила часто не сложны, но на самом деле трудность заключается в знакомстве со структурой дерева синтаксиса JS. Очень рекомендуется здесьastexplorerЭтот инструмент позволяет интуитивно понять структуру AST, соответствующую исходному коду, что удобно для написания правил проверки.

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

  • Для конкретного файла модуля мы можем написать правила ESLint, которые требуют, чтобы имена его переменных соответствовали специальным соглашениям.
  • Для нативного API, инкапсулированного базовой библиотекой команды, запрещено появляться в правилах ESLint, чтобы избежать повторного изобретения.fetchвид проблемы.
  • В случае использования синтаксиса, не соответствующего рекомендациям, мы можем вовремя предупредить вас. Например, обнаружено, что оператор require_илиlodashПри присвоении значений это, вероятно, приведет к резкому увеличению размера пакета, чего можно избежать, написав правила.
  • ...

тест-драйв

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

В package.json плагина будет такой скрипт:

"scripts": {
  "test": "mocha ./tests/**/*.js"
}

В качестве примера мы/testsдобавить в каталогspacing-test.jsТестовый случай, заполните следующее содержимое:

const rule = require('../lib/rules/spacing')
const RuleTester = require('eslint').RuleTester

const ruleTester = new RuleTester()
ruleTester.run('comment', rule, {
  valid: [
    '// 白色相簿 2'
  ],
  invalid: [
    {
      code: '// 白色相簿2',
      errors: [{
        message: 'Something WRONG!',
        type: 'Line'
      }]
    }
  ]
})

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

npm test

Если все тестовые случаи пройдены, значит, плагин готов! Осталось только опубликовать его в NPM и импортировать в свой проект в соответствии с конфигурацией плагина ESLint. В файле README, сгенерированном для вас на первом этапе формирования шаблонов, этот процесс хорошо задокументирован, поэтому я не буду здесь вдаваться в подробности.

Суммировать

Многие студенты, изучающие интерфейс, будут читать документы спецификации ES Spec, чтобы углубиться в техническую глубину. Но, к сожалению, контент на этом уровне зачастую не очень полезен для общего развития бизнеса. Но после того, как у вас появится возможность разрабатывать (а не использовать) плагины ESLint, в сочетании с вашим знакомством с самим JS, у вас появится новое ощущение разблокировки навыка «код для управления кодом»: используйте код для ограничения и оптимизации самого кода. , в этом сила метапрограммирования.

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

Девушка, которая готова добавить вам место в WeChat, должна быть настоящей любовью.

Категории