Comments 38
Список изменений впечатляет, жаль только, что с ExtractTextPlugin они не сильно спешат. Для веба это просто маст хэв, а текущая стабильная версия с новым webpack работать не может — API для плагинов сменили кардинально.
Фича с указанием sideEffects выглядит весьма многообещающе. Очень надеюсь, что она наконец починит Tree shaking.
Не проверял, но хочется верить, что все работает
Вообще непонятно, почему ExtractTextPlugin не встроен в webpack из коробки. Я кое-как смирился с import './style.scss', но деплоить стили в виде гигантского строкового литерала в JS все ещё не готов. До сих пор хорошей практикой остается вставлять стили в head, а скрипты перед </body>.
Но, может быть, нужда в нём отпадёт за счет того что 4.x будет поддерживать типы модулей html и css, то есть их не надо будет заворачивать в JS? Посмотрим
Если вас беспокоит style-loader как fallback для асинхронных чанков, то посмотрите в сторону ExtractCssPlugin. Он выносит весь css из всех чанков.
Не уверен правда, что работает с webpack 4. Но на webpack 3 полёт нормальный.
Меня беспокоит, что такой фичи нету из коробки и надо танцевать с бубном. А менять один плагин на другой (кстати, я что-то так и не нагуглил ExtractCssPlugin) смысла особо не вижу — оба надо отдельно ставить и конфигурировать.
Немного название неправильно написал, вот он.
Ну конфигурация сверх лоадеров там всего несколько строчек
- вызов
new Plugin({filename: 'mask'}); pluginInstance.extract(loadersChain)
Да, отсутствие хорошей поддержки css из под коробки, конечно, немного смущает, тут не поспоришь.
Спасибо.
Что-то это по конфигу не сильно отличается… А в чем преимущество, что-то я туплю? Делает code split для css?
Этот плагин по умолчанию для каждого асинхронного чанка создает свой css чанк. ExtractTextPlugin же выносит текст только из entry чанка.
Давайте рассмотрим на примере.
У вас есть чанки
- app.js — entry point
- common.js — получаемый из commonChunksPlugin
- mainPage.js — асинхронный чанк с функционалом главной страницы
В случае использования ExtractTextPlugin вы получите на выходе
- app.css — css entry поинта, которого будет не очень много
- common.js, mainpage.js — содержат стили внутри js'a через style-loader
В общем-то, в такой схеме ExtractTextPlugin не выглядит особо полезным.
ExtractCssChunksPlugin вообще не имеет опции fallback т.к. она ему не нужна, с помощью этого плагина вы получите следующую структуру:
- app.css — все тоже самое
- common.css — все общие стили
- mainPage.css — стили главной страницы
ExtractCssChunksPlugin — это ИМХО то, как должен работать ExtractTextPlugin по умолчанию.
Минусы этого плагина:
- Возможно не поддерживает webpack 4 (не проверял ещё)
- Дефолтное значение filename может мешать, уж много плагин на себя берёт этим значением, мог бы полагаться на то, что указано в секции output
- Он полагается на ExtractTextPlugin, и это видно в логах. Это само по себе не проблема. Если правильно помню структуру проекта, то проблема в том, что ExtractTextPlugin просто скопипащен (ctrl+c ctrl+v) внутрь ExtractCssChunks. Это, во первых, ужасно. Во вторых, можете забыть о получении фиксов\улучшений ExtractTextPlugin. Поэтому если встретите баг, который был исправлен в ExtractTextPlugin, вероятно он не будет исправлен в ExtractCssChunks.
Но мы используем ExtractCssChunks в продакшне и полёт пока ровный
Да, отсутствие хорошей поддержки css из под коробки, конечно, немного смущает, тут не поспоришь.
В прошлом году нам обещали улучшенную поддержку:
https://medium.com/webpack/the-new-css-workflow-step-1-79583bd107d7
Но что-то с тех пор апдейтов не видно
Как насчёт обратной совместимости? В своё время, когда изучал Webpack, я столкнулся с проблемой: актуальной версией Webpack была 2, которая обратно-несовместимостима с версией 1 (плагины, написанные для версии 1 не работали с Webpack 2 и наоборот), а большая часть плагинов была написана для версии 1; приходилось ультимативно решать, какую версию Webpack использовать, и лучшим выбором являлась версия 1, потому что для неё было намного больше плагинов.
То есть киллер фича 4й версии это -2 строчки в конфиге?
А что насчет http 2? Не отпадает ли надобность в вебпаке как таковом? Не судите строго просто прочитал где-то что с приходом http 2 сборка всего в один файл становится не нужной
Все равно нужен будет live/hot-reload, препроцессоры и минификация для продакшена (для мобильников это всё еще важно) — хотя возможно что этим будет заниматься уже не вебпак.
Ждем возвращение gulp?
Эту стюардессу не то что пора закопать, ей вообще не надо было рождаться:)
Хотя для сборки разного рода библиотек вебпак действительно прекрасен
Неплох. Но они даже сами писали, что для сборки именно библиотек rollup лучше. Да и конфиги у rollup все-таки поприятнее.
Весьма популярное заблуждение. Http2 не решает проблему, которую решает бандлинг.
Давайте представим ситуацию.
У вас есть точка входа, которая импортит класс приложения, который импортит еще модуль и так далее.
Думаю, вы без труда найдете в своем коде, например, 8 уровней импортов.
entry => application => rootComponent => component => anotherComponent => someLibrary => lodash.
Если отказаться от сборки исходников в один\несколько файлов, то возникает следующая ситуация.
- Браузер получает ваш entry point, узнает что ему нужен application
- Получает application, узнает, что нужен rootComponent
- и так далее до 8 уровня
Каждый шаг для браузера — это отдельный запрос со всеми вытекающими. http2 позволяет переиспользовать соединение, однако задержка между вами и пользователем, как ни крути, останется.
Если предположить, что задержка 50мс, то только 400мс уйдет на то, чтобы спросить у вас файлы (не учитывая скачивание, парсинг и всё такое). Если пользователь, не дай бог, с мобильного интернета, то там уже совсем другие цифры.
Решение у этой проблемы есть — сразу говорить пользователю, какие файлы ему понадобятся. Вместо того, чтобы собирать один\несколько файлов, нам теперь нужно строить граф зависимостей, чтобы оптимизировать отправку. Можно и из булки сделать троллейбус, но зачем? Воркфлоу без потерь не упрощается.
Ну и бонусом, бандлинг позволяет очень хорошо оптимизировать код (минификация, дедупликация, tree shaking, лучше гзипуется, легче пересылается по сети)
Чтобы сделать http2 push вам нужно знать, что пушить.
Для того, чтобы знать, что пушить, вам нужен граф зависимостей, чтобы резолвнуть те модули, которые запросит пользователь. Не сказать, чтобы это сильно проще, но это решение, да. Также тут на хабре есть [статья](https://habrahabr.ru/company/badoo/blog/331216/), про то что пока не нужно использовать server push, браузеры его поддерживают по разному и нетривиально его сделать правильно. А если сделать неправильно, то пользователю будет плохо
Ну и есть еще подводные камни, вот пара статей по этому поводу:
* www.contentful.com/blog/2017/04/04/es6-modules-support-lands-in-browsers-is-it-time-to-rethink-bundling
* engineering.khanacademy.org/posts/js-packaging-http2.htm
Есть хороший принцип, простое — просто, сложное — возможно. Но на самом деле он не совсем полон, хорошо когда ещё и переход от простого к сложному происходит без переписывания кода или смены api. Или как в данном случае разумным считаю иметь преднастроенный дефолтный конфиг, с разделами где вписаны все настройки по умолчанию. И конфиг побит на разделы, типа base options, advanced options и expert. И тогда всё просто и понятно. И проще гуглить поведение каждой настройки.
Вашему вниманию — Webpack 4