Сегодня существует множество task-runner'ов, boilerplates для быстрого старта разработки, но зачастую даже в этом случае приходится дорабатывать, писать, разбираться в куче настроечных файлов, и корень проекта зачастую похож на сборище разнообразных конфигов. Работая в разных проектах даже в рамках одной компании зачастую в каждом проекте все устроено по-своему и перед тем как начать с ним работать — сначала требуется прочитать кучку, зачастую увесистых, конфигов, чтобы разобраться — где что и как происходит и откуда растут ноги.
А хочется просто — взять и начать писать код, сразу. И просто писать тесты, легко запустить их, увидеть покрытие. И также получить финальную сборку.
Если вам хочется того же — то возможно вам будет интересно узнать о easymake.
В этой статье я опишу основные проблемы, в решении которых вам может помочь easymake.
1. Скорость старта. Просто взять и начать работать
easymake для простоты можно сравнить с капсульной кофеваркой. Сама по себе easymake не представляет пользы для конечного пользователя, всю ценность представляют пресеты, а easymake лишь обеспечивает их выполнение.
easymake представляет собой исполняемый файл с анализатором параметров командной строки, оркестратор задач и API (которое используется при выполнении задач и работой с конфиг-файлами).
При запуске анализируются переданные параметры и выполняются соотвествующие действия, обычно это либо копирование файлов конфигурации в проект, либо выполнение задачи.
Пресет содержит в себе набор задач и набор файлов конфигурации, а также перечисление пакетов, которые требуются для обеспечения его работы.
Таким образом, чтобы начать разрабатывать с easymake обычно требуется выполнить 5 простых шагов:
npm init
- добавление в devDependencies требуемого пресета (easymake указан в зависимостях к пресету, нет необходимости его прописывать явно)
- в package.json в разделе config.easymake.preset указать имя используемого пресета из пункта 2.
- если в пресете имеется задача на создание начальной структуры проекта — выполнить её (например
easymake --run create-folders
) - Запуск задачи на сборку bundle для разработки (например
easymake --run bundle
)
НАЧИНАЕМ РАБОТАТЬ!
Хотим тестировать и узнать покрытие? — нет проблем: easymake --run test-units
(команда для default-preset'а)
Хотим получить сборку на продакшн — нет проблем: easymake --run bundle --production
(команда для default-preset'а)
С easymake от идеи до начала реализации вас отделяет всего лишь 5 простых шагов.
2. Порядок в работе. Соблюдаем принятые подходы и лучшие практики
Я сейчас открыл 2 крупных проекта, в которых я принимал участие, в одном — 12 настроечных и вспомогательных файлов: скрипты запуска, сборки, публикации, настройки Gulp, Babel, EsLint, Webpack, Karma и др. Скрипты используют переменные среды, конец команды на сборку (npm run bundle) проекта может находится за пределами экрана. В другом — 11, задачи практически те же, реализация — совсем другая. Запуск проектов производится абсолютно по разному.
А теперь представьте что у вас таких проектов не 2, а 22. Кто-то собирает с помощью Gulp, кто-то с помощью Grunt, кто-то тестирует с помощью Jasmine, кто-то с помощью Mocha.
Как это все контролировать? Boilerplate? Отлично вы написали его, раздали, каждый склонировал, начал разрабатывать проект, время идет — конфиги пухнут. Вы решаете добавить какое-то правило в линтер, изменить сборку, или фреймворк тестирования — как синхронизировать это с существующими проектами? 22 раза зайти в каждый проект и руками обновлять конфиги и потом смотреть — а работает ли, а не сломалось ли.
При подходе на основе пресетов easymake вы делаете пресет (либо используете существующий) с типовыми задачами, с типовыми правилами, конфигурациями и утилитами. Каждый, начинающий проект — берет пресет и просто начинает работать в том окружении и с теми практиками, которые приняты.
Вы нашли что можно улучшить? Какие еще действия можно автоматизировать? Один из проектов переопределил конфигурацию пресета и стало лучше? — Обновите пресет. Далее в каждом проекте участники выполнят только одну команду — npm update
— и ваши улучшения уже у них.
Один пресет — решение сотни проблем для многих проектов. Решили сто первую? — 1 команда — и ваше решение используют все.
3. Чистота рабочего места. Я больше не хочу этой копипасты
С чего начинается проект? Конечно с обустройства той инфраструктуры с помощью которой вы будете его собирать, тестировать, запускать и выполнять другие сопутствующие действия. Вы каждый раз пишете эти конфиги с нуля? Ctrl-C + Ctrl-V (или F5 для фанатов :) ) не надоело? А когда открываешь проект и в корне штук 5 разных .rc?
Если у вас есть подходящий пресет, все конфиги лежат в нем, никакого мусора. Если же вам надо что-то переопределить — это конечно можно сделать в виде изменения к нужному конфигу, а если это изменение будет полезно в рамках всего пресета его можно будет легко внести в пресет.
Никаких больше копирований конфигов из проекта в проект, никакого зоопарка настроек. Держим проект в чистоте и порядке.
Еще раз о том что дает использование easymake:
- Стартуем работу за 5 простых шагов
- Используем один пресет — одни подходы и методики разработки, улучшаем их быстро и без проблем.
- Не копипастим конфиги и вообще лучше бы их не видеть в проекте.
easymake всего лишь "почти" очередной task-runner
но, возможно, он поможет вам изменить ваши процессы разработки к лучшему и тратить больше времени на то что действительно важно, и конечно же, получать больше удовольствия от процесса разработки.
В заключении отмечу, что проект создан относительно недавно и находится в стадии разработки, но на текущий момент уже стабильно работающий и активно используемый персонально. Сам easymake врядли будет уже сильно меняться, а вот пресеты — это вещь живая.
На текущий момент имеется 2 пресета: для разработки библиотеки и для разработки web-приложения на React. Если у вас есть желание разработать свой пресет или улучшить существующий — буду рад.
easymake доступен в npm и GitHub.
Ссылки на существующие пресеты: https://github.com/madcode-tech/easymake/wiki
Комментарии (4)
kahi4
19.03.2017 00:59+2А чем Yeoman не угодил?
Ну и да, на моей практике конфиги после boilerplate разъезжаются на несовместимые достаточно быстро в разных проектах.
Ну и да, есть более простые решения через тот же npm, например, что вам мешает вынести конфиги webpack в свой приватный репозиторий?
Вы пишите "И просто писать тесты, легко запустить их, увидеть покрытие", а саму библиотеку тестами не покрыли
А теперь представьте что у вас таких проектов не 2, а 22. Кто-то собирает с помощью Gulp, кто-то с помощью Grunt, кто-то тестирует с помощью Jasmine, кто-то с помощью Mocha.
И как им поможет использование вашей библиотеки? Ну будет 22 презета, кому легче от этого? Допустим, все 22 проекта используют один и тот же презет. А теперь вы его обновляете и пишите статью "иногда копипаста все же не так уж и плохо", потратив неделю на поиски что же поотваливалось в остальных 21 проекте? Или у вас настолько типовые проекты, что все конфиги у всех одинаковые и никогда не возникает задач кастомизации и точной наладки? Везет.
affka
19.03.2017 09:56Понимаю ваши проблемы, тоже одно время надоедали копипасты gulp/webpack конфигов, особенно когда это руками невнимательных разработчиков делалось без включения мозга.
Тоже есть свои webpack-easy gulp-easy, вот только распространять такое за рамки своей комании не советовал бы. Внутри комании — да, это нужно, чтобы стандартизировать, а вот сообществу такие пакеты вряд ли пригодятся, потому что для они неизвестны, неудобны и не покрывают их задач.
elmigranto
19.03.2017 17:34-15 простых шагов
Ну нет, 5 это в пять раз больше, чем максимальное количество.
Плюс стоит учесть, что шаг «добавляем желаемый пресет» совсем не прост — нужно пройти по существующим, оценить насколько они подходят, сравнить выбранные, решить какой лучше.
ChALkeRx
Честно говоря — два раза прочитал (первый — как обычно, второй — пытался вдумываться), прошёл по ссылке, проглядел ридми, ткнул на документацию вашу, посмотрел, что там написано.
И ничего не понял.