Мы рады сообщить, что сегодня стал доступен webpack 4 (Legato).
Его можно скачать через npm или yarn, выполнив:

$> yarn add webpack webpack-cli --dev

или

$> npm i webpack webpack-cli --save-dev

Почему Legato?

Мы хотели завести традицию давать мажорным релизам кодовые имена. Привилегию выбрать имя для проекта мы решили предоставить нашему крупнейшему спонсору на OpenCollective — trivago.

Мы обратились к ним, и вот что они ответили:

Имена наших проектов обычно связаны с музыкой. Например, наш старый
JavaScript-фреймворк назывался Harmony, а новый называется Melody.
На стороне PHP мы используем Symphony с дополнительным слоем, который
называется Orchestra.

Legato значит играть ноты одну за другой без пауз между ними.

Webpack упаковывает "весь фронтенд без пауз/разрывов" (JS, CSS и т.д). Поэтому мы считаем, что
"legato" — хорошее название для webpack.

Patrick Gotthardt из trivago Engineering.

Мы были в восторге, потому что всё, над чем мы работали к этому релизу, как раз и несло в себе идею избавления от зазоров, и чтобы работать с webpack можно было "легато". Большое спасибо trivago за невероятный год спонсорства и за название для webpack 4!

Что нового?

Новшеств в webpack 4 так много, что пост с их полным перечислением был бы просто огромным. Поэтому я упомяну лишь некоторые из них, а с полным списком можно знакомиться в журнале изменений на Github.

webpack 4 БЫСТРЫЙ (до 98% быстрее)

Из сообщества наших бета-тестеров мы получали интересные отчёты о производительности билдов в новой версии, поэтому я сделал опрос, чтобы проверить имеющиеся данные:

(Кто хочет попасть в нашу публикацию по webpack? Нужно, чтобы вы сделали следующее (если возможно): Обновили свой проект до webpack v4 и рассказали нам о времени выполнения билда и размере бандла до и после обновления ответом на этот твит)

Результаты вышли поразительными. Время билда уменьшилось с 60 до 98%! Вот лишь некоторые из ответов, которые мы получили (раз, два).

Благодаря этим отзывам нам удалось обнаружить и исправить несколько важных багов в загрузчиках и плагинах. PS: Мы ещё не реализовали многопоточность и файловый кеш (это запланировано на 5 версию), так что в последующих релизах можно будет ещё сильнее улучшить производительность.

Увеличение скорости сборки было для нас одной из важнейших задач в этом релизе. Можно было бы добавить сколько угодно других фич, но если они неприступны, работают медленно и тратят время разработчиков, то какой смысл? Ждём ваших отзывов с замерами производительности под хештегами #webpack и #webpack4.

Режимы #0CJS и настройки по умолчанию

Мы ввели новое свойство конфигураций, называющееся mode (режим). Есть два режима: development и production, по умолчанию выбирается production. Режим — это способ выбора подходящих настроек по умолчанию, оптимизированных либо по размеру билда (production), либо по времени сборки билда (development).

Чтобы подробнее ознакомиться с режимами, смотрите нашу предыдущую статью.

Значения по умолчанию появились у entry и output. Получается, теперь вам вообще не нужно ничего конфигурировать для начала работы. С использованием режимов ваши конфигурационные файлы будут невероятно маленькими, поскольку большую часть рутинной работы webpack теперь берёт на свои плечи.

Легато значит играть ноты одну за другой без пауз между ними.

Итого у нас появилась платформа, не требующая конфигурации, и мы хотим, чтобы вы её расширяли. Одна из наиболее ценных особенностей webpack — расширяемость, лежащая в его основе. Кто мы такие, чтобы решать, как будет выглядеть ваше #0CJS-решение (zero-config JS)? Когда мы добавим в webpack возможность создавать пресеты конфигов, вы сможете расширять #0CJS так, как того требует рабочий процесс у вас лично, или в вашей компании, или даже в сообществе вашего фреймворка.

До свидания, CommonsChunkPlugin!

Мы избавляемся от CommonsChunkPlugin, добавив вместо него ряд настроек по умолчанию и легко переопределяемого API, называющегося optimize.splitChunks. Теперь из коробки будут работать общие чанки, автоматически генерируемые в различных сценариях.

В этом посте подробнее рассказывается о том, зачем мы это переделали и как выглядит API.

Поддержка WebAssembly

Теперь webpack по умолчанию поддерживает import и export любого локального модуля WebAssembly. Это значит, что теперь вы можете писать загрузчики, позволяющие делать import кода на Rust, C++, C и на других языках, компилирующихся в WebAssembly.

Типы модулей и поддержка .mjs

Исторически в webpack поддерживались только JavaScript-модули. Это доставляло пользователям множество неудобств, когда нет возможности делать бандлы из HTML/CCS и прочего. В нашей новой кодовой базе мы полностью абстрагировались от JavaScript, введя типы модулей. На текущий момент их реализовано 5:

• javascript/auto: (тип по умолчанию в webpack 3) модули JavaScript с
  использованием всех модульных систем: CommonJS, AMD, ESM;
• javascript/esm: модули EcmaScript, остальные модульные системы недоступны (тип по умолчанию для файлов .mjs);
• javascript/dynamic: Только CommonJS и AMD; EcmaScript-модули недоступны.
• json: данные в JSON, доступные через require и import (тип по
  умолчанию для файлов .json)
• webassembly/experimental: модули WebAssembly (экспериментальная
  поддержка, тип по умолчанию для файлов .wasm);

Самое волнительное в этом новшестве то, что позже мы сможем сделать типы модулей для CSS и HTML (запланировано на webpack 4.x и 5). Можно будет делать HTML точкой входа!

Если вы используете HtmlWebpackPlugin

К этому релизу мы дали экосистеме месяц на то, чтобы перевести загрузчики и плагины на использование нового API webpack 4. Однако поскольку Jan Nicklas был занят неотложными делами, мы самостоятельно форкнули и пропатчили html-webpack-plugin. Сейчас его можно установить так:

$> yarn add html-webpack-plugin@webpack-contrib/html-webpack-plugin

Когда Jan вернётся в конце месяца, мы планируем влить наш форк в jantimon/html-webpack-plugin. До тех пор, если у вас имеются проблемы с работой плагина, можете сообщать о них сюда.

Если у вас есть другие плагины или загрузчики, можете ознакомиться с нашим руководством по миграции.

Но и это ещё не всё!

Мы добавили так много фич, что настоятельно рекомендуем ознакомиться с ними в нашем официальном чейнджлоге.

Где документация к версии 4?

Скоро мы допишем руководство по миграции и документацию к 4 версии. Чтобы проследить за прогрессом или помочь нам, заглядывайте в наш репозиторий документации и делайте git checkout next.

Что насчёт \<framework>-cli?

В последние 30 дней мы тесно сотрудничали со всеми фреймворками, чтобы удостовериться, что они готовы поддерживать webpack 4 в своих CLI и прочем. Даже популярные библиотеки типа lodash-es или RxJS поддерживают флаг sideEffects, так что можно сразу уменьшить размера вашего бандла, используя их последние версии.

Команда AngularCLI сообщает, что они планируют выпускать следующую мажорную версию (где-то через неделю) с использованием webpack 4! Если хотите узнать, как у них продвигаются дела, напишите им, и спросите, чем можно помочь (вместо "когда будет готово?").

Что дальше?

Мы уже начали планировать наш следующий набор фич для webpack 4.x и 5! В него войдут (кроме прочего):

• Target для ESM Module
• Файловый кеш
• Перенос поддержки WebAssembly из experimental в stable. Вместе с tree-shaking и вырезанием неиспользуемого кода.
• Пресеты и расширяемое 0CJS. К чёрту конфиги там, где можно обойтись без них!
• Тип модуля CSS, CSS как точка входа (прощай и ты, ExtractTextWebpackPlugin)
• Тип модуля HTML, HML как точка входа
• Тип модуля URL/файл
• Тип модуля <Ваш_собственный>
• Многопоточность
• Переписанный устав организации и "наша миссия"
• Google Summer of Code (скоро будет отдельный пост)

Спасибо. Ещё раз.

Всем нашим контрибьюторам, основной команде, авторам загрузчиков и плагинов, тем, чьи первые коммиты в открытое ПО начались с нашего проекта, кто помогал с поиском неисправностей в коде: мы премного благодарны вам. Этот продукт для вас, и он сформировался благодаря вашим же усилиям.

Мы верим, что 2018 год несёт за собой переход JavaScript из усталого закостенелого Средневековья в прекрасный светлый Ренессанс!

Мы много раз повторяли это ранее, но сообщество — вот то, что делает webpack таким мощным, поддерживаемым и впечатляющим в сегодняшнюю эпоху возрождения JavaScript, в которой мы живём и работаем. Без вас webpack оставался бы всего лишь ещё одним инструментом для билдов.

Нет времени на помощь нашему проекту, но хотите отплатить опенсорс-сообществу сообществу как-то ещё? [Становитесь нашим бэкером или спонсором на OpenCollective (https://opencollective.com/webpack). OpenCollective поддерживает не только нашу основную команду, но и других участников проекта, уделяющих значительную часть своего свободного времени на улучшение нашей организации.