Комментарии 12
Честно говоря — два раза прочитал (первый — как обычно, второй — пытался вдумываться), прошёл по ссылке, проглядел ридми, ткнул на документацию вашу, посмотрел, что там написано.
И ничего не понял.
А чем Yeoman не угодил?
Ну и да, на моей практике конфиги после boilerplate разъезжаются на несовместимые достаточно быстро в разных проектах.
Ну и да, есть более простые решения через тот же npm, например, что вам мешает вынести конфиги webpack в свой приватный репозиторий?
Вы пишите "И просто писать тесты, легко запустить их, увидеть покрытие", а саму библиотеку тестами не покрыли
А теперь представьте что у вас таких проектов не 2, а 22. Кто-то собирает с помощью Gulp, кто-то с помощью Grunt, кто-то тестирует с помощью Jasmine, кто-то с помощью Mocha.
И как им поможет использование вашей библиотеки? Ну будет 22 презета, кому легче от этого? Допустим, все 22 проекта используют один и тот же презет. А теперь вы его обновляете и пишите статью "иногда копипаста все же не так уж и плохо", потратив неделю на поиски что же поотваливалось в остальных 21 проекте? Или у вас настолько типовые проекты, что все конфиги у всех одинаковые и никогда не возникает задач кастомизации и точной наладки? Везет.
Yeoman делает готовую структуру проекта. У меня же несколько иная идея — предоставить только лишь окружение.
Кастомизация конечно часто нужна и она может быть сделана через переопределение нужного конфига пресета.
Также основная идея в том что сам проект отделен от окружения сборки, при этом имея связь с используемым пресетом, который можно обновить при этом не изменяя ничего в самом проекте.
И как раз то и не должно быть 22 пресета, а должен быть 1 и с минимально требуемыми изменениями конфигурации в каждом проекте. Поэтому если обновляется пресет, то вы делаете npm update и работаете с обновленным пресетом.
Касаемо приватного репозитория: конечно, и можно сделать свой приватный пресет и никуда его не выкладывать, но суть то в том, что если вы конфиги берете в каждый создаваемый проект (даже если они лежат где-то отдельно и доступно), то эти конфиги вы загружаете в систему контроля версий вместе с проектом и далее связь с исходным репозиторием конфигов теряется, если они обновляются — вам нужно как минимум обновлять все руками.
Понятно что и пресет можно обновить так что у всех все перестанет работать, но это уже зависит от того кто его разрабатывает.
Тестов пока нет, дело в том что эта утилита вспомогательная, с помощью нее я собираю свои библиотеки, о которых я в скором времени также напишу. Так что тестов пока нет, но появятся.
потратив неделю на поиски что же поотваливалось в остальных 21 проекте?
Если следовать semver, то ничего не отвалится (во всяком случае в теории)
Тоже есть свои webpack-easy gulp-easy, вот только распространять такое за рамки своей комании не советовал бы. Внутри комании — да, это нужно, чтобы стандартизировать, а вот сообществу такие пакеты вряд ли пригодятся, потому что для они неизвестны, неудобны и не покрывают их задач.
Распространять или нет — это уже дело, в общем-то личное, кому-то вероятно чей-то пресет и подойдет, или он его модифицирует или будет развивать.
В общем то можно выгрузить конфигурацию пресета и посмотреть что там, понятно что должно быть и описание пресета. Если утилита окажется полезной кому-то кроме меня я думаю что со временем некоторое количество общеиспользуемых пресетов появится.
5 простых шагов
Ну нет, 5 это в пять раз больше, чем максимальное количество.
Плюс стоит учесть, что шаг «добавляем желаемый пресет» совсем не прост — нужно пройти по существующим, оценить насколько они подходят, сравнить выбранные, решить какой лучше.
easymake — «почти» очередной task-runner для сборки, тестирования и иных задач для node.js