Научитесь элегантно сортировать импортированные модули в коде JavaScript/TypeScript.

Когда ваш проект JavaScript/TypeScript станет больше, вам будет импортировано все больше и больше модулей. Если вы не отсортируете модули должным образом, они будут выглядеть довольно беспорядочно, их будет трудно читать и поддерживать. Однако, если вы сортируете их вручную, это на самом деле очень громоздкая работа. Что еще хуже, если вы работаете в команде, у каждого может быть своя привычка сортировать модули. В результате у нас будут разные шаблоны сортировки в одном репозитории, что не круто.

К счастью, с помощью ESLint и подключаемого модуля import мы можем сортировать модули единообразно. автоматически. В этом посте мы представим конфигурации для ESLint и плагина import для сортировки модулей с помощью Git Hooks и CI Pipelines. С помощью этих инструментов у вас будет единый импорт, который будет выглядеть аккуратно и профессионально.

Чтобы сделать этот учебник более полезным, а команды/фрагменты кода готовыми к использованию для любого проекта JavaScript/TypeScript из коробки, мы введем настройки для ESLint, Prettier, lint-staged и Husky, которые вместе составляют конвейер статической проверки кода. Основное внимание в этой статье будет уделено настройке ESLint и подключаемому модулю import для сортировки модулей. Ключевые настройки для других библиотек также будут кратко представлены. Подробную информацию об этих библиотеках см. в следующих статьях:

Установка зависимостей

Нам нужно установить ряд библиотек для стилей и линтинга. Рекомендуется устанавливать их как зависимости, а не глобально, чтобы они могли сохраняться в pacakage.json и, таким образом, могли использоваться всеми членами команды.

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

Обратите внимание, что TypeScript и его зависимости также установлены. Если ваш проект представляет собой простой код JavaSript, вы можете удалить TypeScript и его зависимости из приведенной выше команды. Точно так же команды и фрагменты кода в других частях сообщения также будут использоваться для кода TypeScript. Их довольно просто адаптировать для проектов JavaScript. Вам просто нужно удалить соответствующие разделы для TypeScript, и они обычно хорошо работают для JavaScript.

Кроме того, Husky устанавливается другим способом, который является рекомендуемым способом для Husky.

Настройте собственные правила сортировки ESLint

На самом деле ESLint может выполнять автоматическую сортировку импортированных модулей по правилу sort-imports. Однако он не может различать встроенные, внешние и внутренние модули и, следовательно, не является полностью автоматическим. Тем не менее, он хорошо справляется с сортировкой элементов в одном и том же операторе импорта, а именно для сортировки нескольких функций/классов/интерфейсов, импортированных из одного модуля.

В этом руководстве этот файл конфигурации ESLint будет использоваться в качестве отправной точки для TypeScript, а этот — для JavaScript. Обратите внимание, что мы удалим правила форматирования, поскольку вместо них они будут реализованы библиотекой Prettier. Полный файл конфигурации можно найти позже в посте.

Настройки правила sort-imports будут следующими:

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

Настройте плагин импорта

Мы установили подключаемый модуль eslint-plugin-import и можем использовать его для определения встроенных, внешних и внутренних модулей и их соответствующей сортировки. Настройки этого плагина довольно подробные. Однако обычно настройки по умолчанию будут работать правильно для большинства проектов. Вы можете настроить их в соответствии со своим вкусом и требованиями, когда это необходимо.

Правила для подключаемого модуля import задаются правилом import/order, и в этом сообщении используются следующие настройки:

Ключевые моменты:

  • Как предложено в ключе и значениях, groups используется для определения порядка различных групп модулей. В этом примере перечислены все разрешенные группы, но вы можете просто оставить нужные. Кроме того, группы можно объединять, заключая их в квадратные скобки. Например, мы можем использовать ["sibling", "parent"] для объединения родственных и родительских импортов. Отметьте эту ссылку, если хотите узнать определения различных групп.
  • Если для newlines-between задано значение always, мы всегда будем помещать новую строку между различными группами, что желательно и может значительно облегчить чтение импорта.
  • С помощью alphabetize мы будем сортировать импорт внутри каждой группы в алфавитном порядке. Здесь мы игнорируем регистр и сортируем их в порядке возрастания.

Настройка поддержки TypeScript для плагина импорта

Мы установили плагин eslint-import-resolver-typescript, который добавляет поддержку TypeScript в eslint-plugin-import. Настройки этого плагина очень просты, нам просто нужно указать расположение tsconfig.json.

Измените путь на tsconfig.json соответственно для вашего собственного проекта. Дополнительные настройки этого плагина можно найти здесь.

Полный файл конфигурации (.eslintrc.js)

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

Конфигурации других библиотек

Чтобы создать функциональный конвейер статической проверки кода, нам также необходимо настроить Prettier, lint-staged и Husky. Мы просто кратко представим файлы настроек для справки.

Конфигурация для Prettier (.prettierrc.json)

Обратите внимание, что здесь используется ключ длины строки printWidth, а не max_line_length, который используется в файле .editorconfig.

Больше конфигураций для Prettier можно найти здесь.

Конфигурация для lint-staged (.lintstagedrc.json)

Этот немного особенный и стоит сказать еще несколько слов:

  • Библиотека lint-staged позволяет выполнять анализ только тех файлов, которые находятся в промежуточном состоянии, но не всех файлов.
  • По умолчанию lint-staged добавит к команде файлы, которые находятся в промежуточном состоянии. Обычно это желательно. Однако для tsc мы не можем указать tsconfig.json вместе с входными файлами. Это известная проблема, и нам нужно жить с ней сейчас. Чтобы решить эту проблему, нам нужно использовать трюк bash, который игнорирует аргументы, переданные команде. Подробнее о трюке читайте в этой теме.

Конфигурация для Хаски (.husky/pre-commit)

Папка .husky была создана командой npx husky-init && npm install. Там есть файл pre-commit, в который вы добавляете команды для запуска в хуке pre-commit. В этом примере мы можем просто запустить команду lint-staged, которая, в свою очередь, запустит команды linting. Кроме того, в package.json добавлен новый скрипт "prepare": "husky install", который создаст папку .husky, если она еще не создана.

Используйте статический конвейер проверки кода

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

Затем код можно улучшить на основе сообщений об ошибках.

Все файлы, представленные в этом посте, можно найти в этом репозитории.

Бонус: настроить конвейер CI на стороне сервера

Тревога! Настроенный выше хук перед коммитом можно пропустить с флагом --no-verify при создании коммита. Это может произойти намеренно или случайно. Однако этого нельзя допускать, когда код помещается в удаленный репозиторий. Чтобы решить эту проблему, мы можем настроить конвейер непрерывной интеграции (CI) на стороне сервера, который будет проверять код при его отправке в удаленный репозиторий.

В своей работе я использую GitLab, поэтому конвейер CI настроен в .gitlab-ci.yml. Однако это должно работать аналогично для других инструментов CI.

Содержание .gitlab-ci.yml:

Ключевые моменты здесь:

  • Нам нужно использовать образ Docker для Node.js и установить туда пакеты. Обратите внимание, что GitLab автоматически загрузит все файлы в контейнер Docker, и будут установлены зависимости, указанные в package.json (или package-lock.json, если они доступны).
  • Мы не должны изменять файлы на стороне сервера, но должны позволить конвейеру выйти из строя, если этап стилизации или проверки не пройден. Обратите внимание, что для Prettier нам нужно указать флаг --check, чтобы шаг не прошел, если код отформатирован неправильно. Без флага --check статус выхода будет равен 0, даже если код отформатирован неправильно.

Ура, если вы, наконец, добрались сюда! Мы представили все инструменты, необходимые для настройки конвейера статической проверки кода для проектов JavaScript/TypeScript, уделив особое внимание настройке автоматической сортировки импортированных модулей. Рекомендуется опробовать пайплайны самостоятельно, чтобы лучше понять все настройки.

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

Статьи по Теме: