Сегодня существует множество task-runner'ов, boilerplates для быстрого старта разработки, но зачастую даже в этом случае приходится дорабатывать, писать, разбираться в куче настроечных файлов, и корень проекта зачастую похож на сборище разнообразных конфигов. Работая в разных проектах даже в рамках одной компании зачастую в каждом проекте все устроено по-своему и перед тем как начать с ним работать — сначала требуется прочитать кучку, зачастую увесистых, конфигов, чтобы разобраться — где что и как происходит и откуда растут ноги.

А хочется просто — взять и начать писать код, сразу. И просто писать тесты, легко запустить их, увидеть покрытие. И также получить финальную сборку.


Если вам хочется того же — то возможно вам будет интересно узнать о easymake.


В этой статье я опишу основные проблемы, в решении которых вам может помочь easymake.


1. Скорость старта. Просто взять и начать работать


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


easymake представляет собой исполняемый файл с анализатором параметров командной строки, оркестратор задач и API (которое используется при выполнении задач и работой с конфиг-файлами).


При запуске анализируются переданные параметры и выполняются соотвествующие действия, обычно это либо копирование файлов конфигурации в проект, либо выполнение задачи.


Пресет содержит в себе набор задач и набор файлов конфигурации, а также перечисление пакетов, которые требуются для обеспечения его работы.


Таким образом, чтобы начать разрабатывать с easymake обычно требуется выполнить 5 простых шагов:


  1. npm init
  2. добавление в devDependencies требуемого пресета (easymake указан в зависимостях к пресету, нет необходимости его прописывать явно)
  3. в package.json в разделе config.easymake.preset указать имя используемого пресета из пункта 2.
  4. если в пресете имеется задача на создание начальной структуры проекта — выполнить её (например easymake --run create-folders)
  5. Запуск задачи на сборку 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:


  1. Стартуем работу за 5 простых шагов
  2. Используем один пресет — одни подходы и методики разработки, улучшаем их быстро и без проблем.
  3. Не копипастим конфиги и вообще лучше бы их не видеть в проекте.

easymake всего лишь "почти" очередной task-runner


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

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

На текущий момент имеется 2 пресета: для разработки библиотеки и для разработки web-приложения на React. Если у вас есть желание разработать свой пресет или улучшить существующий — буду рад.


easymake доступен в npm и GitHub.


Ссылки на существующие пресеты: https://github.com/madcode-tech/easymake/wiki

Поделиться с друзьями
-->

Комментарии (4)


  1. ChALkeRx
    19.03.2017 00:03
    +2

    Честно говоря — два раза прочитал (первый — как обычно, второй — пытался вдумываться), прошёл по ссылке, проглядел ридми, ткнул на документацию вашу, посмотрел, что там написано.


    И ничего не понял.


  1. kahi4
    19.03.2017 00:59
    +2

    А чем Yeoman не угодил?


    Ну и да, на моей практике конфиги после boilerplate разъезжаются на несовместимые достаточно быстро в разных проектах.


    Ну и да, есть более простые решения через тот же npm, например, что вам мешает вынести конфиги webpack в свой приватный репозиторий?


    Вы пишите "И просто писать тесты, легко запустить их, увидеть покрытие", а саму библиотеку тестами не покрыли


    А теперь представьте что у вас таких проектов не 2, а 22. Кто-то собирает с помощью Gulp, кто-то с помощью Grunt, кто-то тестирует с помощью Jasmine, кто-то с помощью Mocha.

    И как им поможет использование вашей библиотеки? Ну будет 22 презета, кому легче от этого? Допустим, все 22 проекта используют один и тот же презет. А теперь вы его обновляете и пишите статью "иногда копипаста все же не так уж и плохо", потратив неделю на поиски что же поотваливалось в остальных 21 проекте? Или у вас настолько типовые проекты, что все конфиги у всех одинаковые и никогда не возникает задач кастомизации и точной наладки? Везет.


  1. affka
    19.03.2017 09:56

    Понимаю ваши проблемы, тоже одно время надоедали копипасты gulp/webpack конфигов, особенно когда это руками невнимательных разработчиков делалось без включения мозга.
    Тоже есть свои webpack-easy gulp-easy, вот только распространять такое за рамки своей комании не советовал бы. Внутри комании — да, это нужно, чтобы стандартизировать, а вот сообществу такие пакеты вряд ли пригодятся, потому что для они неизвестны, неудобны и не покрывают их задач.


  1. elmigranto
    19.03.2017 17:34
    -1

    5 простых шагов

    Ну нет, 5 это в пять раз больше, чем максимальное количество.

    Плюс стоит учесть, что шаг «добавляем желаемый пресет» совсем не прост — нужно пройти по существующим, оценить насколько они подходят, сравнить выбранные, решить какой лучше.