Как автоматизировать наиболее повторяющиеся задачи вашего проекта JavaScript с открытым кодом

1656642149 kak avtomatizirovat naibolee povtoryayushhiesya zadachi vashego proekta javascript s otkrytym

Сара Дайан

l4KWfaMEr8VioPD4CjL9JVjUQUaJd7mgYGpZ
Фото Чеда Кирхоффа на Unsplash

Когда я начинал свою карьеру, мой наставник сказал мне:

«Хороший разработчик – ленивый разработчик. Не тратьте время на повторяющиеся задачи, а тратьте его на создание автоматизированных процессов. Компьютер работает на вас, и он всегда будет быстрее вас».

Это было еще в 2010 году, и набор инструментов, который мы располагали, был более дефицитным, чем сегодня. Однако этот совет остался во мне до сих пор.

От исполняемых сценариев до конфигураций Yeoman, настроек IFTTT и рабочих процессов Automator, не говоря уже о множестве приложений, которые я использую, чтобы помочь мне выполнять каждое движение на компьютере. Я воспринимаю автоматизацию как игру и получаю от нее большое удовольствие.

itLJ8msFhVY-dLL8j2FAttAoPEcDrGl7ZroX

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

Чтобы разобраться в этом, я решил показать вам подробные настройки для реального проекта – моего последнего проекта с открытым исходным кодом, Dinero.js.

Отказ от ответственности: Это не учебное пособие о том, как создать библиотеку с открытым исходным кодом, а скорее обзор того, что я использую, как и для чего. Для подробного пошагового пособия я рекомендую курс egghead.io «Как написать библиотеку JavaScript с открытым исходным кодом» Кента С. Доддса.

Управление зависимостями

npm и пряжа

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

К счастью, теперь у нас есть надежный и надежный менеджер внешних зависимостей: npm. Если вы пришли с PHP, вы можете увидеть npm как Composer и Packagist вместе. Он предоставляет богатейшее внешнее хранилище из существующих и великолепный интерфейс командной строки для обработки зависимостей.

Многие люди (включая меня) предпочитают использовать Yarn: более быстрый CLI, который интегрирует мощную систему кэша, распараллелирует загрузку и обеспечивает офлайн-режим. Теперь Пряжа есть только слой поверх хранилища npm: он просматривает пакеты npm, но позволяет использовать их инструмент.

Стиль кодирования и условности

EditorConfig

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

EditorConfig — это файл конфигурации, который живет в проекте и определяет параметры редактора. Каждый раз, когда вы работаете над проектом, который имеет .editorconfig файл, ваш редактор будет соответствовать его правилам.

Большинство редакторов могут анализировать .editorconfig файлов, но если это не так, вы можете скачать плагин.

Красивее

Одним из инструментов, за который я больше всего благодарен, является Prettier. Я так копаю его, что имею его как сценарий npm в своем проекте и как плагин для редактора кода. Вот такая глубокая моя любовь.

Prettier решает проблему споров по поводу стиля кодирования и траты времени на просмотр кода. Больше никаких горячих дискуссий вокруг простых кавычек против двойных кавычек. Больше нет отклоненных запросов на вытягивание, потому что вы забыли пробел перед if скобка.

И, прежде всего, больше не нужно тратить время на форматирование кода вручную. Prettier самоуверен, поэтому вы будете иметь ограниченное пространство для настройки правил по умолчанию. И это к лучшему: это не то, на что стоит тратить свое драгоценное время

ESLint

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

Это то, о чем заботится ESLint. Он не перепишет ваш файл, как это делает Prettier, но вы получите предупреждение в терминале.

там есть некоторые общие территории между ESLint и Prettier, поэтому я рекомендую:

  1. Сначала вы запускаете Prettier, а затем ESLint.
  2. Вы используете инструмент, который гарантирует, что они не конфликтуют друг с другом, например eslint-config-prettier.

Commitizen и cz-conventional-changelog

Вероятно, вы начинаете видеть закономерность: да, Я очень люблю условности. Я лучше доверяю конвенции и сосредоточусь на своей работе, чем попаду в кроличью нору велосипедного сброса, и сообщения о комитах относятся к этой категории. Теперь идея обычных сообщений комитов не такова только чтобы сделать хорошие обязательства, речь идет об автоматизации большого числа рабочего процесса КИ.

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

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

То же касается версии.

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

Это то, что Commitize и cz-conventional-changelog снимают с вас. Вместо того чтобы фиксировать обычный способ, вы запускаете сценарий, который задает вам вопросы. Затем он зафиксирует для вас сообщение с надлежащим форматом, соответствующее указаниям Angular Git Commit. Позднее, когда вы разворачиваете семантическое освобождение, эти сообщения о фиксации будут использоваться для создания журнала изменений и определения нового номера версии. Автоматически. Хорошо, верно?

ворсинчатый

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

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

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

У Dinero.js вот как выглядит моя поэтапная конфигурация lint:

{  "lint-staged":    { "*.js": ["npm run lint!", "git add"]  }}

The npm run lint! команда последовательно запускает два других сценария: npm run format (хуже), то npm run lint (ESLint). Каждый раз, когда я пытаюсь зафиксировать JavaScript, Prettier переформатирует его. Затем ESLint выполнит сканирование: если оно пройдет, коммит будет выполнен. Иначе ESLint выдаст ошибку, и комит будет прерван.

Документация

JSDoc

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

С JSDoc все, что вам нужно сделать это добавить комментарий с определенными тегами и описаниями над каждой важной частью кода (функцией, модулем и т.п.).

{  /**   * Returns the currency.   *   * @example   * // returns 'EUR'   * Dinero({ currency: 'EUR' }).getCurrency()   *   * @return {String}   */  getCurrency() {    return currency  }}

Этот блок документа содержит описание, один пример и вводимое возвращаемое значение.

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

rh8AAuIHvLoVLCEvo239DqAfI9sgcMCXhXcQ
Вот как блок документов для Dinero.getCurrency выглядит как когда-то собранный на веб-сайт.

Почему не ESDoc?

Младший ребенок, ESDoc, использует другой подход, чем JSDoc. Кроме всего прочего, ESDoc был разработан, чтобы хорошо работать с классами ES6 и конкретным кодом в целом. Недостатком того, что он не поддерживает заводские функции.

Фабричные функции – это динамические генераторы объектов, поведение, которое ESDoc не охватывает. Если вы попытаетесь задокументировать фабрику с помощью ESDoc, сгенерированная документация вернется пустой.

В моем случае фабрики являются строительными блоками Dinero.js, объясняющими мой выбор.

Если ваш проект использует синтаксис класса ES6, ESDoc удовлетворит все ваши потребности. В противном случае используйте JSDoc: он поддерживает все функции ES6, а также более «старые» шаблоны, такие как фабричные функции и оригинальный синтаксис для конструкторов.

Algolia DocSearch

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

Algolia – лучший поисковый сервис. Их (бесплатное) решение DocSearch позволяет создавать отличные условия документации для ваших пользователей. DocSearch — это служба по требованию: как только ваши документы будут готовы, отправьте им URL, и вы получите фрагмент кода для добавления на свой веб-сайт.

Тесты

Мокко и чай

Модульное тестирование имеет решающее значение. Если вы только можете сделать один для качества кода, забудьте о линтировании, забудьте о форматировании, забудьте о проверке кода и написать модульные тесты.

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

Теперь, если вы только начинаете, модульное тестирование может показаться несколько пугающим. Хорошая новость состоит в том, что они не обязательны: благодаря таким инструментам, как Mocha и Chai, написание тестов становится очень близким к веселье.

Вот отрывок из моих модульных тестов для Dinero.js:

import chai from 'chai'import Dinero from '../../src/dinero'
const expect = chai.expect
describe('Dinero', () => {  describe('#getAmount()', () => {    it('should return the right amount as a number', () => {      expect(Dinero({ amount: 500 }).getAmount()).to.equal(500)    })    it('should return the default amount as a number when no amount is specified', () => {      expect(Dinero().getAmount()).to.equal(0)    })  })})

Этот файл JavaScript, называемый «spec», использует структуру Mocha и библиотеку утверждений Chai. Общедоступный API создан так, чтобы выглядеть как подлинные английские предложения: даже люди, не имеющие технических знаний, могут прочесть файлы спецификаций и понять, что происходит. Это облегчает работу новым участникам, поскольку кривая обучения почти не существует.

Тесты с использованием Mocha и Chai сначала запускаются с Node.js, что означает, что он ожидает модулей CommonJS для спецификации и исходных файлов. Но, благодаря Babel, нам не нужно писать CJS, если мы этого не хотим: мы все равно можем использовать модули ES и транспилировать их на лету во время выполнения тестов! Вот как я могу включать модули import вместо require и все еще имеют полностью рабочие тесты.

Стамбул и комбинезон

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

Istanbul – это инструмент покрытия кода. В Dinero.js я использую nyc, его интерфейс командной строки для создания отчетов.

Z4W6jmCZb744cuSylmvaqFofFtaZrrXX7mdL
Отчет о Стамбуле после завершения модульных тестов.

Istanbul создает отчеты по всем форматам: терминальный выход, HTML, а также LCOV. Это особенно полезно при использовании с онлайн-сервисами, такими как Coveralls. Каждый раз, когда Travis CI запускает сборку, он выполняет тесты, а nyc создает файл LCOV. Затем он посылается в Coveralls, генерирующий подробную статистику. Это особенно полезно для взносов: когда кто-то посылает запрос на получение, бот Coveralls автоматически отвечает с обновленным покрытием. Это способствует облегчению и ускорению просмотра кода.

Строить

Вавилон

ES6+ принес удивительные функции JavaScript, но они все еще поддерживаются не везде. Это не значит, что вы должны ждать, прежде чем начать использовать его: познакомьтесь с Babel.

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

Я написал весь исходный код Dinero.js, используя такие функции ES6 как функции жирной стрелки и модули ES. Каждый раз, когда я выпускаю версию, Babel транспилирует исходные файлы в код ES5, который можно распространять.

Babel также полезен модульному тестированию. Для этого я использую Node.js, еще не поддерживающий модули ES, поэтому не может работать с моими исходными файлами. Благодаря Babel я могу транспилировать их на лету всякий раз, когда запускаю свою тестовую команду.

Свернуть

Когда ваша библиотека будет готова, ее нужно упаковать, чтобы ею могли пользоваться разные люди в разных средах. Некоторые будут использовать его с Node. Некоторым он пригодится непосредственно в браузере как тег сценария. Остальные захотят, чтобы он был включен в собственный проект как модуль ES и в комплекте с собственными инструментами.

Rollup – это сборник модулей, как Webpack или Parcel, но он особенно полезен для создания библиотек JavaScript. Он разработан для работы с модулями ES и превращает их в любой формат модуля, который вы хотите.

В прошлые времена код, который мы написали, был именно кодом, который оказался в производстве. Если вы хотите, чтобы ваш код был максимально повсеместным, вы должны вручную завернуть его в шаблон UMD. Сегодня вы можете кодировать именно так, как вам заблагорассудится, и посылать разные комплекты для каждого благодаря пакетам модулей, таким как Rollup. Нужна версия UMD? Вот так. Вместе с AMD, CJS, IIFE и т.д.

CI

GitHub

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

Тревис CI

Вы можете рассматривать Travis CI как руководителя процесса постройки вашего проекта.

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

Выполните модульные тесты. Если они пройдут:

  • Выполните покрытие кода
  • Сборник версии (файлы dist)
  • Перекомпилируйте документы
  • Отметьте версию и разместите тег на GitHub
  • Увеличьте версию и отправьте сборку в npm
  • Напишите запись в журнале изменений
  • Отправьте файлы документов на страницы GitHub

Иначепочинить вещи, промыть и повторить.

Прежде чем установить CI конвейер, я попытался сделать это вручную. Угадай, что? не было один раз когда я сделал это правильно. почему Поскольку как типичный человек, я склонен к ошибкам и отвлекаюсь. Кроме того, машины хорошо реагируют на заказ. Они сделают именно то, что вы хотите как вы этого хотите. Все, что вам нужно сделать, это хорошо указать это, один раз.

Travis CI является бесплатным для проектов с открытым кодом и хорошо интегрируется со сторонними службами. Все, что вам нужно сделать, это войти с помощью своей учетной записи GitHub и синхронизировать проект. По умолчанию Travis будет выполнять тесты каждый раз, когда вы будете отправлять данные в удаленный репозиторий. Тогда вы можете сказать Тревису, что делать, когда тесты пройдены с помощью a .travis.yml файл в корне проекта.

семантико-увольнение

Прежде чем разбираться в том, что делает semantic-release, вам нужно понять семантическое управление версиями (он же «semver»).

Короче говоря, semver – это сделка, основанная на числовом формате XYZ, соответственно MAJOR, MINOR и PATCH:

  • Когда вы исправляете ошибку, но ваши изменения обратно совместимы, вы увеличиваете ПАТЧ.
  • Когда вы добавляете функцию, но ваши изменения остаются обратно совместимыми, вы увеличиваете МИНОР.
  • Когда вы вносите какие-либо обратные несовместимые изменения, вы увеличиваете MAJOR.

Это помогает людям, зависящим от вашего проекта, знать, могут ли они безопасно обновить и упрощает управление зависимостями в целом.

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

Короче говоря, семантический релиз заботится о версиях за вас. Вы не имеете права голоса. Он использует ваши традиционно написанные сообщения комиттов, чтобы решить, какой будет следующая версия. Добавьте его к своему конвейеру CI (например, в вашем рабочем процессе Travis CI), и вы получите полностью автоматизированную систему, которая будет читать ваши комиты, изменять версию, добавлять теги, отправлять на GitHub, отправлять npm и записывать ваш журнал изменений. Фу.

Не слишком ли много?

Это может выглядеть как многие вещи, которые нужно настроить. «Неужели мне все это нужно?» Вы можете удивиться. Я отвечу несколькими вопросами: сколько задач вы сейчас выполняете вручную? Сколько у вас времени занимает релиз? Насколько вы уверены, когда это делаете? Когда вы последний раз выполняли весь рабочий процесс, ничего не забыв?

Я лично не могу развернуть релиз вручную без шпаргалки. Линтирование, форматирование, тестирование, покрытие кода, документы, сборник, семантическое управление версиями, выпуск, обновление журнала изменений, все в таком порядке, но убедитесь, что я на правильной ветке… тьфу. Очень надеюсь, что я не ошибся! Этот процесс отнимает столько времени, вы можете испортить его многими способами, и он постоянно отнимает у вас столько времени от реальной работы, что автоматизировать это должно быть простой проблемой.

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

Что с вами? Каков ваш рабочий процесс для веб-проектов? Что облегчило вашу жизнь? Пообщайтесь со мной об этом в Twitter!

Кроме того, вы можете просмотреть другие мои статьи в моем блоге.

Добавить комментарий

Ваш адрес email не будет опубликован.