Как установить webpack 4
Перейти к содержимому

Как установить webpack 4

  • автор:

Installation

This guide goes through the various methods used to install webpack.

Prerequisites

Before we begin, make sure you have a fresh version of Node.js installed. The current Long Term Support (LTS) release is an ideal starting point. You may run into a variety of issues with the older versions as they may be missing functionality webpack and/or its related packages require.

Local Installation

The latest webpack release is:

GitHub release

To install the latest release or a specific version, run one of the following commands:

npm install --save-dev webpack # or specific version npm install --save-dev webpack@version>
tip

Whether to use —save-dev or not depends on your use cases. Say you’re using webpack only for bundling, then it’s suggested that you install it with —save-dev option since you’re not going to include webpack in your production build. Otherwise you can ignore —save-dev .

If you’re using webpack v4 or later and want to call webpack from the command line, you’ll also need to install the CLI.

npm install --save-dev webpack-cli

Installing locally is what we recommend for most projects. This makes it easier to upgrade projects individually when breaking changes are introduced. Typically webpack is run via one or more npm scripts which will look for a webpack installation in your local node_modules directory:

"scripts":  "build": "webpack --config webpack.config.js" >
tip

To run the local installation of webpack you can access its binary version as node_modules/.bin/webpack . Alternatively, if you are using npm v5.2.0 or greater, you can run npx webpack to do it.

Global Installation

The following NPM installation will make webpack available globally:

npm install --global webpack
warning

Note that this is not a recommended practice. Installing globally locks you down to a specific version of webpack and could fail in projects that use a different version.

Bleeding Edge

If you are enthusiastic about using the latest that webpack has to offer, you can install beta versions or even directly from the webpack repository using the following commands:

npm install --save-dev webpack@next # or a specific tag/branch npm install --save-dev webpack/webpack#
warning

Take caution when installing these bleeding edge releases! They may still contain bugs and therefore should not be used in production.

Урок 1. Webpack 4+. Настройка и установка Webpack

Webpack 4+

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

скачать урок скачать исходники

Все уроки курса:

Комментарии (5)

Количество уроков: 12

Продолжительность курса: 01:44:51

Автор: Владилен Минин

Меня зовут Владилен Минин. Я являюсь Seniour Front End разработчиком. Моя основная деятельность – это создание функционала на JavaScript, приложения любой сложности. Также занимаюсь обучением людей с различным уровнем навыков: от полных новичков до профессионалов в своей области.

Описание курса: В данном курсе вы познакомитесь с последней версией технологии WebPack. В данном курсе вы создадите приложение, в котором будут показана реализация всех базовых и часто используемых задач при современной веб разработке.

Все права защищены © 2023
Бернацкий Анрей Васильевич
Служба поддержки

Webpack 4 и разделение конфигурационного файла на модули

Привет, Хабр! Сегодня я расскажу вам о Webpack 4 с разделением кода на отдельные модули, а также о интересных решениях, которые помогут вам быстрее собрать сборку на webpack 4. В конце, я предоставлю свою базовую сборку на webpack c самыми необходимыми инструментами, которую вы в последствие сможете расширить. Данная сборка вам поможет понять данный материал, а также возможно поможет быстрее написать свою реализацию и быстрее решить возможные проблемы.

Основная идеология данной сборки — это корректное разделения кода внутри конфигурационного файла для удобства использования, чтения и чистоты webpack.config.js. Необходимые модули и плагины для dev и prod версии(а также для разделения функционала в главном файле) будут находиться в отдельной папке webpack и из неё импортироваться для соединения с главным конфигом.

Зачем нужен такой подход?

С постепенным ростом количества модулей, плагинов и т.д, которыми обрастает ваша сборка на вебпаке, конфигурационный файл растёт как на дрожжах. Со временем данный файл становится трудно читаемым, а изменять его под конкретный проект, если какие-то модули в нём не используется становится труднее, а хочется чего-то универсального. Поэтому требуется чёткая организация кода.

Что нам понадобится?

Мы будем использоваться плагин webpack-merge.

Создаём папку webpack и выносим все отдельные модули в отдельные файлы. Например, webpack/pug.js, webpack/scss.js и экспортируем из них эти функции.

module.exports = function() < return < module: < rules: [ < test: /\.pug$/, loader: 'pug-loader', options: < pretty: true, >, >, ], >, >; >; 

Файл webpack.config.js. В данном файле мы их подключаем, и с помощью данного плагина удобно и быстро соединяем.

const merge = require('webpack-merge'); const pug = require('./webpack/pug'); const common = merge([ < entry: < 'index': PATHS.source + '/pages/index/index.js', 'blog': PATHS.source + '/pages/blog/blog.js', >, output: < path: PATHS.build, filename: './js/[name].js', >, plugins: […], optimization: < … >, >, pug(), ]); 

Теперь если у нас есть новая задача, под которую нужен новый модуль, плагин, лоадер, то мы выносим его в отельный модуль(файл) и помещаем в папку webpack, а затем подключаем его в главный конфигурационный файл, сохраняя конфиг максимально чистым.

Настройки для production и development

Сейчас мы с помощью банального if закончим наше разделение, к которому мы стремились, и настроим наш вебпак под эти два типа разработки, благодаря чему станет окончательно удобно пользоваться данным инструментом, а так же в будущем сможем гибко и просто настраивать его под любой другой проект, или же расширять в текущем. Для экспорта в ноду(для самой работы вебпака) в webpack 4 мы используем следующую конструкцию:

module.exports = function(env, argv) < if (argv.mode === 'production') < return merge([ common, extractCSS(), favicon(), ]); >if (argv.mode === 'development')

В объект common мы подключаем то, что используется и на проде и в разработке, а в условиях подключаем только те модули, которые необходимы в этих случаях.

Теперь хотелось бы поговорить об основных особенностях webpack 4 относительно webpack 3

  • Для быстрого запуска, webpack 4 не нуждается в webpack.config.js, ему теперь необходима лишь точка входа (index.js)
  • В новой версии webpack command line interface вынесен в отдельный пакет и нужно установить webpack-cli.
  • Для запуска webpack 4, нужно (иначе будет warning) в скриптах указать mode (режим работы) —mode production или —mode development, в зависимости от ключа меняется работа вебпака. Режим development направлен для ускорения сборки. В production варианте направлено всё на итоговую минификацию кода.
  • Для того что бы создать common.js и common.css файлы, более не используется CommonsChunkPlugin, за это теперь отвечают splitChunks и используется следующая конструкция:

 optimization: < splitChunks: < cacheGroups: < 'common': < minChunks: 2, chunks: 'all', name: 'common', priority: 10, enforce: true, >, >, >, >, 

В вебпак 3 – это было бы так в plugins:

new webpack.optimize.CommonsChunkPlugin(< name: 'common ', >)

Соответственно в чанках в HtmlWebpackPlugin подключаем (тут без изменений).

 plugins: [ new HtmlWebpackPlugin(< filename: 'index.html', chunks: ['index', 'common'], template: PATHS.source + '/pages/index/index.pug', >), ], 
module.exports = function() < return < devtool: 'eval-sourcemap', >; >; 

На этом я хотел бы завершить свой рассказ и предоставить свою базовую сборку — ссылка на webpack 4, которая возможно вам поможет в работе и освоение. Спасибо за внимание!

  • Веб-разработка
  • JavaScript
  • Системы сборки

Webpack 4: обзор обновлений

На днях вышла новая версия популярной системы сборки Webpack 4.0. Команда опубликовала большой Changelog и восторженный пост на Medium с описанием обновлений системы.

К текущему моменту не все изменения описаны в официальной документации. В этой заметке — обзор новых возможностей и проблем, с которыми вы можете столкнуться при обновлении.

Режимы сборки

Добавлен обязательный параметр —mode, определяющий один их трех режимов сборки: production, development и none, от которых зависят различные оптимизации и внешний вид бандла. Режим production оптимизирован под уменьшение размера сборки, а development — уменьшение времени сборки. В режиме none все оптимизации отключены.

А еще можно сконфигурировать собственный режим, отключив или включив определенные оптимизации с помощью опций optimization.* в конфиге. Доступные настройки отсутствуют в документации, зато их описал основатель Webpack Тобиас Копперс в блоге на Medium.

import() CommonJS-модулей

Больше нельзя подключать CommonJS-модули через import(). То есть либо используйте require, либо пишите модули по стандарту ES6 modules.

CommonJS

const a = require(«./a») module.exports = < a, b: 2 >

ESM

import a from «./a» export default < a, b: 2 >

Удаленные плагины

  • NoEmitOnErrorsPlugin или NoErrorsPlugin (не создает сборку при ошибках). Доступен из коробки как optimization.noEmitOnErrors. Включен по умолчанию в production mode
  • ModuleConcatenationPlugin (объединяет несколько модулей в одном замыкании, чем уменьшает бандл и ускоряет выполнение). Теперь это делается из коробки в production mode, либо включается настройкой optimization.concatenateModules
  • NamedModulesPlugin (улучшает внешний вид имени модуля при Hot Module Replacement, который обновляет только изменившиеся части сборки). Теперь это опция optimization.namedModules, которая включена по умолчанию в режиме development
  • NewWatchingPlugin (улучшает пересборку при изменениях) — больше не требуется
  • CommonsChunkPlugin (выделяет общие части нескольких точек входа в отдельную сборку) — заменен на набор API `optimize.splitChunks`. Авторы даже написали пост, сделали ролик и опубликовали gist на эту тему.

Минификация

Отдельным пунктом про UglifyJsPlugin. Он, наконец, научился поддерживать ES6 модули, но в базовой конфигурации он больше не нужен — для минификации сборки используется опция optimization.minimize = true, которая по умолчанию включена в режиме production. Не используемый код (dead code) Webpack теперь тоже вырезает без помощи UglifyJs.

Плагин или функцию, которая будет заниматься минификацией, можно переопределить в optimization.minimizer.

Типы модулей

Изначально Webpack был ориентирован именно на сборку JavaScript-файлов. Но впоследствии его стали применять для сборки всего на свете: CSS, HTML, картинок и тд, в процессе испытывая боль с конфигурацией точек входа, лоадерами и плагинами. Теперь появились Module Types:

  • javascript/auto — JavaScript-модуль в формате CommonJS, AMD или ESM
  • javascript/esm — строго ES-модуль. По умолчанию применяется для .mjs файлов.
  • javascript/dynamic — либо CommonJs, либо AMD
  • json — JSON-файл, которые теперь можно подключать напрямую через require или import. По умолчанию включен для .json файлов
  • webassembly/experimental — модуль WebAssembly, по умолчанию для .wasm файлов

Типы модулей определяются либо автоматически по расширению файла, либо задаются с помощью свойства module.rules[].type в конфиге.

По словам разработчиков, введение типов позволит им в следующих обновлениях Webpack добавить возможность создавать CSS, HTML и другие сборки, без точки входа на JavaScript.

Webpack-cli вынесен в отдельный проект

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

npm install —save-dev webpack-cli
yarn add —dev webpack-cli

Поддержка WebAssembly

Появилась возможность подключать WebAssembly-модули через import или require. Другими словами, в сборку можно подключать бинарные скрипты C++, C, Rust и другие, но для этого потребуются соответствующие лоадеры.

Сами модули WebAssembly тоже могут «реквайрить» другие .js и .wasm модули.

Поддержка sideEffects: false в package.json

Свойство sideEffects в файле package.json в значении false сообщает, что пакет не содержит действий, изменяющих состояние внешних переменных, DOM-узлов и тд.

Он упрощает встроенный Tree Shaking и оптимизирует сборку переиспользуемых частей кода.

sideEffects можно переопределить для каждого модуля в свойстве module.rules

Магические комментарии к динамическим импортам

В Webpack конструкции вида

modulesList.forEach( module => require(‘src/’ + module) );

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

Возможность создавать динамические импорты реализуется с помощью ContextReplacementPlugin, который заранее включает в сборку файлы по заданным паттернам. Еще один вариант динамических импортов — асинхронная подгрузка модулей через Code Splitting.

Суть обновления в том, что теперь вы можете фильтровать файлы в динамических импортах с помощью магических комментариев webpackInclude и webpackExclude. В документации описания этой возможности нет, но делается примерно так:

import( /* webpackExclude: «system.js» */ ‘module’ );

Больше информации при сборке

  • Добавлена валидиция настроек плагинов. Поддерживаются не все, но какие — не уточняется.
  • ProgressPlugin, включаемый опцией —progress, теперь выводит названия плагинов рядом с процентами прогресса сборки
  • Опция Stats теперь выводит названия вложенных модулей
  • Некорректное значение options.dependencies приводит к ошибке сборки
  • Больше информации при ошибках подгрузки chunk-модулей.
  • Более понятное сообщение о том, что какой-то плагин был удален

Работа с переменными окружения

Если раньше вы передавали чувствительные данные, хранящиеся в переменных окружения с помощью DefinePlugin, то теперь это можно сделать «из коробки» с помощью optimization.nodeEnv: true, тогда они автоматически попадут в proccess.env.NODE_ENV.*

Этой возможности нет в Changelog, но она есть в исходниках. И, видимо, в определенный момент появится в документации.

Source Maps

Опция devtools теперь поддерживает свойства include, test и exclude.

В режиме development по умолчанию генерируются source maps типа eval. Для более детальной настройки source maps разработчики рекомендуют использовать SourceMapDevToolPlugin.

Дефолтная конфигурация

Для простейшей сборки больше не требуется webpack.config.js, тк ряд обязательных параметров получил значения по умолчанию.

  • Точка входа по умолчанию — ./src/index.js
  • Output-директория, в которой окажется сборка — ./dist
  • Режим сборки по умолчанию — production

Если вы занимаетесь разработкой лоадеров или плагинов для Webpack, обратите внимание на список изменений в API без обратной совместимости.

Troubleshooting

Если вы решили обновить версию Webpack, то начать лучше с удаления всех модулей и плагинов (а лучше — всей локальной папки node_modules), после чего установить новый Webpack и затем — поставить плагины заново. Это сэкономит время на решении проблем с совместимостью и обновлением зависимостей.

Дальше разбор некоторых частых ошибок.

The CLI moved into a separate package: webpack-cli. Please install ‘webpack-cli’ in addition to webpack itself to use the CLI. -> When using npm: npm install webpack-cli -D -> When using yarn: yarn add webpack-cli -D

Error: webpack.optimize.UglifyJsPlugin has been removed, please use config.optimization.minimize instead.

— отключить плагин, заменить на optimization.minimize: true

WARNING in configuration The ‘mode’ option has not been set. Set ‘mode’ option to ‘development’ or ‘production’ to enable defaults for this environment.

— передать —mode production (или development) при запуске скрипта webpack

npm WARN extract-text-webpack-plugin@2.1.2 requires a peer of webpack@^2.2.0 but none was installed.

— избавиться от ExtractTextWebpackPlugin (разработчики за полтора месяца тестирования беты Webpack 4 не предоставили обновления), либо, потратив N-времени в гугле, найти и установить нестабильную альфу.

npm i —save-dev [email protected]

Зачем это все

Шон Ларкин, технарь Microsoft Edge и один из ведущих разработчиков Webpack и Angular Cli, провел опрос в твиттере с предложением сравнить скорость сборки до и после обновления на 4 версию. По его словам, прирост составил до 98%

Что дальше

А дальше последуют патч-версии (читай, багфиксы), одна из которых вышла пока писался этот материал. Существенный прирост в скорости сборки во многом был обусловлен рефакторингом ядра, который позволит реализовать старые featue-реквесты и свежие идеи на обновленном API. Шон уже озвучил ряд нововведений, которые появятся либо в минорных обновлениях четвертой версии, либо, вероятнее всего, в Webpack 5.

  • ESM Module Target
  • Persistant-кэширование (видимо, не будет сбрасываться при остановке watch)
  • Поддержка WebAssembly-модулей станет stable, добавление Tree Shaking
  • Расширение 0CJS — то есть сборки без конфигурации. По сути — расширение пула дефолтных значений.
  • «Многопоточная» сборка.
  • CSS Module Type. Можно будет создавать отдельные CSS сборки со своей точкой входа. Шон попрощался с ExtractTextWebpackPlugin (и со всеми контрибьютерами этой разработки)
  • То же самое с HTML Module Type
  • URL/File Module Type. То есть в качестве точки входа скоро сможет выступить даже изображение.
  • [Create-Your-Own] Module Type. Вот что назвается, рефакторинг.

Шон завершает публикацию словами о Ренессансе JavaScript и «переосмыслении» миссии Webpack.

А мы продолжаем работать.

If you like this article, share a link with your friends

Read more

We talk about interesting technologies and share our experience of using them.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *