Один из способов облегчить боль при начале работы с проектом JavaScript - скрыть все нюансы множества сторонних инструментов, которые вам нужно использовать: транспилер, линтер, тестовый фреймворк и т. Д. Как мы можем это сделать? Просто следуя этому простому рецепту:
- Предложите несколько команд CLI с сокращенными параметрами. Эти команды будут вызывать сторонний инструмент, передавая набор предопределенных параметров: наиболее распространенных или тех, которые имеют больше смысла в вашем сценарии.
- Используйте файлы конфигурации по умолчанию. Установите значения, которые, по вашему мнению, будут использоваться в 99% проектов в 99% случаев. Посыпьте кучей комментариев, объясняющих, что делает каждый вариант и почему он есть. Если возможно, добавьте внешнюю ссылку для получения дополнительной информации.
- Предложите способ переопределения конфигурации пользователем. Разрешить импорт и изменение значений по умолчанию, создание файла шаблона (на основе файла по умолчанию) или и то, и другое.
Это в основном то, что делают многие другие проекты. Возьмем create-react-app как один из наиболее распространенных примеров.
Такой подход дает некоторые преимущества:
- В 99% случаев вам просто нужно выполнить одну простую команду без дополнительных опций, не записывая никаких конфигураций. В остальном 1% случаев у вас есть свободный путь к отступлению.
- Ваши команды CLI могут иметь общий API. Нет необходимости помнить, была ли опция отладки _1 _, _ 2_ или
--logLevel debug
для данной команды. Вы используете--debug
везде (потому что это имеет для вас больше смысла). - Скрывая и инструмент, и конфигурацию, вы можете переключиться на другой инструмент. Это может потребовать некоторого переноса кода, но это все еще возможно. Используя этот подход, я переключился с мокко на шутку в проекте, где практически нет драматизма.
Хорошо, покажи мне код
Мы создаем команду prettify
, которая обернет Prettier, чтобы отформатировать наш код JavaScript.
Примечание. чтобы упростить и сократить пример, мы не проводим никаких проверок работоспособности и предполагаем множество вещей.
Скрипт prettify
Скрипт prettify
разделен на две основные части. Вариант разбора и исполнения.
Парсинг опций осуществляется с помощью библиотеки командир (альтернатив много, но нам вроде как нравится). Мы определяем три варианта настройки Prettier:
-c
,--config
для использования определенного файла конфигурации. Если не установлен, команда будет использовать конфигурацию по умолчанию.-w
,--write
, чтобы сделать красивее перезаписывать исходные файлы вместо того, чтобы сбрасывать код наstdout
(поведение по умолчанию).--debug
, чтобы Prettier выводил свои отладочные сообщения.
Команда prettier
понимает около 40 опций. Мы поддерживаем только те, которые используем в 99% случаев.
На этапе выполнения мы создаем финальную prettier
команду, используя переданные параметры. Если конфигурация не передана, мы используем конфигурацию по умолчанию. Запускаем команду с помощью spawnSync. Обратите внимание, что мы работаем синхронно и возвращаем код состояния подпроцесса, чтобы правильно поддерживать конкатенацию команд в оболочке.
Наконец, чтобы запустить команду, мы добавляем исполняемый prettify
скрипт.
Конфигурация по умолчанию
Команда prettify
также использует файл по умолчанию prettier.config.js
, расположенный в пакете awesome-tools
. Он определяет наши предпочтительные значения конфигурации и тщательно прокомментирован, чтобы быть полезным после извлечения.
Выброс
Чтобы извлечь конфиг, воспользуемся другой командой: eject
. О парсинге опций сказать нечего. На этапе выполнения мы просто копируем файлы конфигурации по умолчанию для извлеченной конфигурации в корень проекта.
Упаковка
И последнее, но не менее важное: нам нужно добавить запись bin
в наш package.json
, чтобы объявить двоичные файлы нашего пакета.
Вот и все. Готов опубликовать и поделиться.
Теперь вы можете добавить этот пакет в свой проект devDependencies
и начать выполнение команды prettify
. Затем попробуйте eject
, измените конфигурацию и посмотрите, как теперь ведет себя команда.
Бесконечность не предел!
Это был простой пример, иллюстрирующий суть дела. Вы можете расширить его, добавив столько команд, сколько вам нужно. Рефакторинг вещей. Добавьте несколько проверок работоспособности. Вы можете пойти еще дальше и сделать гораздо больше: смешать мел, чтобы улучшить и раскрасить вывод, добавить средство проверки версий, поддержать Windows с перекрестным порождением, добавить поддержку типа вы имели в виду? или сделайте выбросы обнаруживаемыми с помощью eject
, и это лишь некоторые из них.