Comments 10
Зачем все эти сложности, если можно все делать npm-ом на системных пайпах? Gulp плагины это всегда обертки, и они либо сквозят багами, либо нет недостающих фич, либо нужных оберток просто нет, в то время как для npm есть вообще все, что может быть для сборки js. К тому-же настроить сборку на npm в разы быстрее и проще, чем через gulp. А главное, npm — стандартный способ, в то время как gulp — костыли.
Отличная статья в тему.
Отличная статья в тему.
Gulpfile является в своем роде makefile для проекта. В него можно засунуть как dev-штучки, к примеру создание нового контроллера на AngularJS, с шаблоном и записью в роутер, так и production, к примеру компиляция статики Django и перемещение её в другую папку. Просто это удобно и всё на своих местах.
Удобно в теории. На практике с первым багом обертки gulp с невнятным error message понимаешь, что приходится лезть в код модуля, лежащего в основе плагина gulp и писать репорт автору gulp-плагина на гитхаб, который в 50% случаев будет проигнорен, в 50% — пофикшен через 2-3 недели. После n-кратного натыкания на эту ситуацию, понимаешь, что почему-бы просто не сделать build.js, использующий те же нативные модули с внятными ошибками, понятным и хорошо задокументированным API, и если хочется — на тех же стримах (пайпах из gulp, только стандартных).
Этот подход более эффективен в силу того, что авторы конечных модулей, как правило, очень заинтересованы в их успешности и занимаются их поддержкой, в то время как авторы оберток для gulp в целом относятся к ним холодно. Более того, у конечных модулей, возьмем, к примеру, компилятор из ES6 в ES5, как правило, есть множество конкурентов, и если один модуль проваливается, можно просто переключиться на другой. В случае, если использовать обертки gulp, ты автоматически привязан к конкретному модулю.
Но build.js, как правило, также является сложной альтернативой, хотя и уже в разы более гибкой.
Большинство задач, будь то компиляция статики для django или создание нового контроллера для angular легко решается через скрипты npm, запускаясь не `gulp collectstatic`, а `npm run collectstatic`, где в package.json что-то вроде
Но в целом, конечно, дело вкуса. Если большой проект уже на gulp, то перевести его на чистый npm требует усилий. У меня это заняло несколько часов, но результат и сэкономленные поныне нервы стоили того.
Этот подход более эффективен в силу того, что авторы конечных модулей, как правило, очень заинтересованы в их успешности и занимаются их поддержкой, в то время как авторы оберток для gulp в целом относятся к ним холодно. Более того, у конечных модулей, возьмем, к примеру, компилятор из ES6 в ES5, как правило, есть множество конкурентов, и если один модуль проваливается, можно просто переключиться на другой. В случае, если использовать обертки gulp, ты автоматически привязан к конкретному модулю.
Но build.js, как правило, также является сложной альтернативой, хотя и уже в разы более гибкой.
Большинство задач, будь то компиляция статики для django или создание нового контроллера для angular легко решается через скрипты npm, запускаясь не `gulp collectstatic`, а `npm run collectstatic`, где в package.json что-то вроде
"scripts": {
"collectstatic": "./manage.py collectstatic"
}
Но в целом, конечно, дело вкуса. Если большой проект уже на gulp, то перевести его на чистый npm требует усилий. У меня это заняло несколько часов, но результат и сэкономленные поныне нервы стоили того.
В целом, вы правы, пользоваться инструментом, на который забил разработчик, не стоит.
Но в этом и прелесть Gulp, что вы можете использовать нативные инструменты.
Например, Browserify, подключается напрямую, без посредника-плагина.
Для удаления файлов можно использовать npm-модуль del, это тоже очень просто.
Если же не использовать систему сборки, а собственный build.js, то будет некоторое количество стандартного кода по разбору аргументов CLI и настройке параметров сборки — и получится свой велосипед, который придется переносить из проекта в проект.
Поэтому лучше использовать одну из существующих систем сборки, я выбрал Gulp, потому что он мне показался лучше Grunt
Но в этом и прелесть Gulp, что вы можете использовать нативные инструменты.
Например, Browserify, подключается напрямую, без посредника-плагина.
Для удаления файлов можно использовать npm-модуль del, это тоже очень просто.
Если же не использовать систему сборки, а собственный build.js, то будет некоторое количество стандартного кода по разбору аргументов CLI и настройке параметров сборки — и получится свой велосипед, который придется переносить из проекта в проект.
Поэтому лучше использовать одну из существующих систем сборки, я выбрал Gulp, потому что он мне показался лучше Grunt
Ну под аргументы есть тоже много инструментов: nomnom, yargs, minimist. Они тоже очень удобны и стандартны, в отличие от gulp (с gulp не перейдешь так просто на grunt, или, там, brunch, mimosa итп).
Использование жестко одной системы сборки для всего (как одного фреймворка, UI-библиотеки, и т. п.) противоречит анархичному духу ноды, крупные фреймворки и проекты имеют тенденцию разваливаться. Как минимум, рассчитывать при разработке своего проекта на какой-то один «божественный» фреймворк это недальновидно, как класть все яйца в одну корзину. Штуки, пытающиеся вобрать в себя всё вызывают недоверие. Нужный набор атомарных взаимозаменяемых плагинов, соответствующих концепции разделения ответственности в долгой перспективе выигрывает.
Использование жестко одной системы сборки для всего (как одного фреймворка, UI-библиотеки, и т. п.) противоречит анархичному духу ноды, крупные фреймворки и проекты имеют тенденцию разваливаться. Как минимум, рассчитывать при разработке своего проекта на какой-то один «божественный» фреймворк это недальновидно, как класть все яйца в одну корзину. Штуки, пытающиеся вобрать в себя всё вызывают недоверие. Нужный набор атомарных взаимозаменяемых плагинов, соответствующих концепции разделения ответственности в долгой перспективе выигрывает.
А скажите кто-нибудь человеку, далёкому от node:
— инкрементальную компиляцию эти штуки (grunt/gulp/npm/whatever) умеют?
— можно как-нибудь заставить эти штуки работать «на лету» — т.е. обнаруживать изменения файлов и перекомпилировать что нужно?
— можно ли эти штуки вставить прямо в веб-сервер? Чтобы я шел на /CSS/MainCSSBundle.css — и оно по-необходимости перекомпилировало, и отдавало свеженькое?
— инкрементальную компиляцию эти штуки (grunt/gulp/npm/whatever) умеют?
— можно как-нибудь заставить эти штуки работать «на лету» — т.е. обнаруживать изменения файлов и перекомпилировать что нужно?
— можно ли эти штуки вставить прямо в веб-сервер? Чтобы я шел на /CSS/MainCSSBundle.css — и оно по-необходимости перекомпилировало, и отдавало свеженькое?
1. Инкрементальная компиляция — дело компилятора, а не инструмента сборки. Надо смотреть что вы компилируете. Некоторые штуки, типа typescript компилят только изменившиеся файлы. А вот у LESS инкрементальной компиляции нет — каждый раз перекомпилируется вся структура.
2. Можно. У многих инструментов есть свой вотчер, как у browserify — watchify. Но есть и более общие тулзы, типа watch, где можно задать свои действия в колбеке на изменения в директории.
3. Можно. gulp-webserver, grunt-connect, а также специфичные для проектов: browserify-server,…
2. Можно. У многих инструментов есть свой вотчер, как у browserify — watchify. Но есть и более общие тулзы, типа watch, где можно задать свои действия в колбеке на изменения в директории.
3. Можно. gulp-webserver, grunt-connect, а также специфичные для проектов: browserify-server,…
2. Есть в комплекте, поглядите доку и примеры.
3. Проще сделать обратное неварное — livereload модуль подключить.
3. Проще сделать обратное неварное — livereload модуль подключить.
UFO just landed and posted this here
Спасибо, очень полезные 5 копеек для этого поста.
load-grunt-config никак не уменьшает размер общего описания сборки. Конечно, в нескольких файлах читать удобнее, но все равно читать приходится много.
grunt-concurrent я смотрел, Gruntfile c concurrent есть в репозитории с benchmark. Он помог собрать быстрее, но не так быстро как gulp.
Идея с jit заслуживает внимания, ее можно применить и в gulp, чтобы оптимизировать импорты исходя из запускаемых задач.
С последним замечанием просто соглашусь. Я упростил для наглядности доклада, в реальности все как вы и говорите
load-grunt-config никак не уменьшает размер общего описания сборки. Конечно, в нескольких файлах читать удобнее, но все равно читать приходится много.
grunt-concurrent я смотрел, Gruntfile c concurrent есть в репозитории с benchmark. Он помог собрать быстрее, но не так быстро как gulp.
Идея с jit заслуживает внимания, ее можно применить и в gulp, чтобы оптимизировать импорты исходя из запускаемых задач.
С последним замечанием просто соглашусь. Я упростил для наглядности доклада, в реальности все как вы и говорите
Sign up to leave a comment.
Сборка проектов с помощью Gulp.js. Семинар в Яндексе