Комментарии 5
сложилось впечатление что этот редактор построен на технологиях ради технологий.
+2
Простите но:
Или на русском: мы сообщаем Gulp за какими файлами нужно следить. Если кто-то из них обновился, то при помощи Webpack он соберёт скрипт из зависимостей и кусочков Js-кода и превратит Sass в Css. Дальше, он попросит браузер обновить страницу при помощи browserSync.зачем этот костыль? Вебпак все это делает сам в том числе и сообщит клиенту какой модуль обновился и пришлет новый модуль, дальше останется только обработать это событие.
0
Я думаю, что это не костыль, а попытка не смешивать мух с котлетами. Задача Webpack — объединять файлы и резолвить зависимости. Он может сообщать, что файл обновился, обновлять браузер, превращать Sass в Css и минифицировать его, но описание процесса сборки приложения — не его основная задача.
С другой стороны в Task Runner'ах (Gulp, Grunt и т.д.) основная возможность — описание процесса сборки проектов. В Gulp используют идеи Stream'ов, это значит, что можно задать процесс сборки приложения в таком виде: для всех файлов *.sass нужно применить такие-то плагины, если в процессе произошла ошибка нужно что-то залогировать (или к примеру откатиться до предыдущей версии), дальше нужно сохранить файл с расширением css в такую-то папку и обновить браузер. Так же можно писать операторы ветвления, то есть разделять на Production и Developer режим (или не собирать приложения после 3 часов ночи и говорить, что пора спать). В таком жизненном цикле Wepback — просто ещё одна утилита, учавствующая в процессе сборки.
Конечно, можно для всего этого использовать Webpack и это отличный подход для проектов с простым процессом сборки. Но использовать Webpack для сложного процесса сборки, включающего разлив на сервера, запуск тестов, статический анализ кода и другие плюшки, куда больший костыль.
С другой стороны в Task Runner'ах (Gulp, Grunt и т.д.) основная возможность — описание процесса сборки проектов. В Gulp используют идеи Stream'ов, это значит, что можно задать процесс сборки приложения в таком виде: для всех файлов *.sass нужно применить такие-то плагины, если в процессе произошла ошибка нужно что-то залогировать (или к примеру откатиться до предыдущей версии), дальше нужно сохранить файл с расширением css в такую-то папку и обновить браузер. Так же можно писать операторы ветвления, то есть разделять на Production и Developer режим (или не собирать приложения после 3 часов ночи и говорить, что пора спать). В таком жизненном цикле Wepback — просто ещё одна утилита, учавствующая в процессе сборки.
Конечно, можно для всего этого использовать Webpack и это отличный подход для проектов с простым процессом сборки. Но использовать Webpack для сложного процесса сборки, включающего разлив на сервера, запуск тестов, статический анализ кода и другие плюшки, куда больший костыль.
+1
Это костыль, хотя бы потому что вебпак при запуске в `watch` загружает все дерево в память и следит за изменением файлов и только теми которые реально используются в проекте и при их изменении он осуществляет сборку сразу а не начинает пересобирать все с нуля, как это сделано в вашем случае.
Про деплой и тесты это вы уже сами додумали, я ничего подобного не писал.
Про деплой и тесты это вы уже сами додумали, я ничего подобного не писал.
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Разбираемся в DevOps и Js на примере Dillinger.io