Пособие по webpack

[@kossmak]

Всё-таки авторитет, известность автора статьи/перевода имеет значение.
Если бы я эту статью сам в оригинале нашел, только лишь пробежал бы глазами «ага, можно будет потом вернуться, когда-нибудь, наконец, разобраться».
Из ваших же рук, материал уже отобранный, прошёл фильтрацию, одобрен и рекомендован к изучению читателю.
Спасибо, годный тьюториал. А то с Grunt'ом как-то сходу не пошло.

[@qtuz]

Шутка в тему:
— А как в этот Webpack'e подключить стили?
— Ну тут все просто, ставишь precss, postcss-loader, postcss-import, css-loader, style-loader, file-loader, normalizr, normalizr.css, autoprefixer
— Поставил все как вы сказали, но картинки не загружаются.
— Очевидно вы забыли установить image-webpack-loader

[@comerc]

"hot reloading" — нет такого понятия.

// "Live Reloading" и "Hot Module Replacement", соответственно: 
$ webpack-dev-server  --inline --hot

[@chupo22]

Мне понравился этот скринкаст скринкаст по webpack, может кому-то поможет разобраться с ним.

[@Tauyekel]

Удивительно насколько понятным стал для меня webpack, для человека вчера познакомившимся с nodejs, и не изучавший ни разу gulp/grunt. Спасибо за статью, написано очень понятным языком, что даже бегиннеры поймут с чем есть вебпак.

[@Vitaljok]

Спасибо за статью!

Допустим, мы пишем простую страницу...

Мне кажется это основная проблема подобных туториалов.
Всё упомянутые инструменты, будь то Gulp, Grunt, bower, browsery или webpack, хороши на простых примерах.
Но как их использовать на реальных проектах, в которых десятки модулей, специфичные требования, какие-нибудь не стандартные библиотеки?

В частности, про webpack мне было бы интересно почитать про:
— как настраивать различные окружения (например, dev для локального запуска, а prod с минификацией и ссылками на реальные бэкенды);
— как собирать готовый билд, который потом можно выкатывать в продукцию (не просто js-бандл, а отдельная директория / zip / jar со всем необходимым);
— как интегрировать всё это с процессами бэкенда (аля, написал «gradlew build» и на выходе получил и фронт и бэк).

У меня есть смутные предчувствия что одним webpack-ом тут не обойтись.

[@k12th]

Часть ответов есть здесь: https://habrahabr.ru/company/plarium/blog/309230/.

[@k12th]

Отдельная директория с отдельными ассетами (вместо бандла) получается при использовании extract-text-webpack-plugin.
zip (а уж из него можно же сделать jar) делается zip-it-loader.
Интеграция с gradle делается как и везде: cd frontend/dir && npm run build.

[@serf]

— как настраивать различные окружения (например, dev для локального запуска, а prod с минификацией и ссылками на реальные бэкенды);

Элементарно, на основе переданных переменных окружения, у вас ведь вся инфраструктура Node.js в руках. В деталях реализация может быть разной, например используя webpam-merge модуль, ограничений нет.

— как собирать готовый билд, который потом можно выкатывать в продукцию (не просто js-бандл, а отдельная директория / zip / jar со всем необходимым);

Как вам более удобно так и собирать, у меня допустим Maven билдит Java и вместе с этим весь фронт, включая и Webpack и Gulp и прочий зоопарк.

— как интегрировать всё это с процессами бэкенда (аля, написал «gradlew build» и на выходе получил и фронт и бэк).

Как вам более удобно так и интегрировать. Webpack — винтик в общем стеке и нет проблем его интегрировать куда-либо.

[@likerRr]

Webpack позволяет избавиться от bower и gulp/grunt

Это заявление не правда и новичками может быть понято не верно, т.к. раскрыто не полностью.

Вместо bower'а для установки и управления клиентскими зависимостями, можно использовать стандартный Node Package Manager (npm)

Да, вместо bower-а можно использовать npm, но Webpack вас этому не обязывает и вообще ему до этого нет дела.

Вебпак также может выполнять большинство задач grunt/gulp'а

grunt/gulp и webpack не взаимозаменяемые инструменты, т.к. их область применения совершенно разная. grunt и gulp могут быть полностью заменены webpack-ом только в том случае, если их задачами была только сборка проекта.

Знаю, что это перевод, уточнения, скорее, для читателя.

[@serf]

grunt и gulp могут быть полностью заменены webpack-ом только в том случае, если их задачами была только сборка проекта.

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

[@likerRr]

У grunt\gulp и webpack разная философия.

Первые запускают задачи, из частых — скомпилить стили (sass, less), минифицировать и склеить js, почистить папки. При чем так же умеют их запускать по отдельности и\или комбинировать.

Webpack же в свою очередь комплексное решение для сборки проекта, где каждый файл\сущность это модуль. Он не может отдельно собрать css или js, он делает все сразу (нет, ну конечно вы можете наплодить файлы конфигураций и запускать webpack указывая эти файлы, но зачем?).

Я уже отмечал, что эти инструменты могут существовать вместе, выполняя свои задачи. Тот же gulp может служить «запускатором» задачи сборки проекта webpack-ом. Пример из жизни: был проект, состоящий из подпроектов и gulp использовался, чтобы запускать сборку каждого из них. А сборщикам были где кто — то gulp, то webpack.

На gulp/grunt можно навесить задачи деплоя, миграций и многое другое, что не касается сборки проекта. Поэтому идеей моего негодования было именно то, что webpack может заменить gulp/grunt не в большинстве случаев, а именно тогда, когда на эти инструменты возлагались задачи сборки проекта и ни для чего более они не использовались.

[@serf]

Я ведь то же самое выше написал :) grunt/gulp раннеры, по сути голый JS облагороженные некоторой не слишком жесткой структурой, поэтому очевидно свобода полная, а webpack декларативная вещь. Это как например сравнить Ant c Maven в Java мире, при этом их тоже можно использовать вместе.