Так что же такое Webpack? Возможно, вы пришли сюда, потому что вас интересует именно веб-пакет. Или, может быть, вы подумали, что это вкусная еда, и захотели ее попробовать. В любом случае мы будем изучать Webpack с нуля. Пристегните ремни безопасности!

Вот что говорит Википедия о Webpack

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

Так что все это? Я сам задаюсь вопросом. Понятно, что Webpack имеет какое-то отношение к модулям и комплектации. Но что такое модуль? Становится труднее ценить, не имея ничего, что можно показать. Начнем с HTML 101:

<script src="module1.js"></script>
<script src="module2.js"></script>
<script src="module3.js"></script>
<script src="module4.js"></script>

Это обычное дело для любого веб-разработчика. Но что-то не так. Аранжировка сценариев имеет значение. Кроме того, он становится медленным, поскольку браузеру необходимо загрузить все сценарии. Уф !!

Но затем мы перешли на использование чего-то вроде Gulp, Grunt или других подобных им опций. Каков их конец? Тогда мы могли бы сделать что-то вроде этого:

// build-config.js
var scripts = [
  'module1.js',
  'module2.js',
  'module3.js',
  'module4.js'
].concat().minify().dest('build.js');
// referencing
<script src="build.js"></script>

Это лучше, потому что мы делаем только один вызов сценария, и это быстрее, чем в предыдущей реализации. Но нам все еще нужно что-то сделать с порядком, в котором мы размещаем скрипты в build-config.js. Еще один минус в том, что код может взаимодействовать только через глобальные переменные. Это странно, поскольку загрязнение глобального пространства имен - плохая практика, которая приводит к множеству проблем, которых следует избегать.

В Webpack есть кое-что интересное - График зависимостей. Сегодня у нас есть модули CommonJS и даже ES6. Мы строим только то, что нам действительно нужно. Видеть это:

// module1.js
module.exports = {
 sayHi: () => console.log('saying hi')
}
// module2.js
const { sayHi } = require('./module1.js');

В module1.js мы только сказали, что хотим, чтобы sayHi был выставлен извне (с module.exports object), и импортировали его в module2.js с помощью деструктуризации. Откуда метод require()? Похоже, это тот, кто определил, что мы что-то экспортируем в module1.js, и знает, как это сделать. Браузер не понимает require() , поскольку это не глобальное значение. Инструменты сборки понимают это и знают, как им пользоваться.

С Webpack мы можем сделать что-то совершенно другое. Он позволяет использовать require на любом статическом ресурсе. Это может быть применено к файлам js (как показано выше), изображениям (png, gif и т. Д.), Таблицам стилей (css, sass и т. Д.).

// An example with images
<img src={require('../images/food.png')} />

Хм. Это становится все сложнее. Естественно думать, что Webpack работает с файлами JavaScript, но как он может работать с png файлами? У Webpack есть загрузчики, отвечающие за это.

module: {
  rules: {
    test: /\.png/,
    loader: 'file-loader'
  }
}

В результате Webpack сканирует require вызовов, ссылающихся на ресурсы с расширением файла, совпадающим с test в rules. Я расскажу об этом подробнее в одном из следующих постов.

Из того немного, что показано, очень ясно, что в любой момент один файл зависит от другого или актива. Webpack называет это зависимостью. Webpack всегда предоставляется файл входа либо в командной строке, либо в файле конфигурации. Отсюда он строит граф зависимостей, который включает в себя все модули, необходимые приложению (будь то код или не код). Затем он упаковывает их в небольшие пакеты (блоки), которые загружаются браузером.

Еще кое-что. Возможно, вы слышали о Webpack Dev Server. Это небольшой сервер Express, который собирает ваши активы в соответствии с конфигурацией вашего веб-пакета. Он предназначен для местного развития. В основном он обслуживает статические файлы (о чем следует помнить) через порт (можно изменить) на вашем локальном хосте.

Хорошо, мы закончили объяснять, что такое Webpack. Каковы преимущества его использования?

  • Вы не сможете выполнить развертывание с отсутствующими активами. Это вносит некоторую стабильность в наши развертывания.
  • Вы контролируете, как обрабатываются ваши активы.
  • Перезагрузка горячего модуля и замена горячего модуля. (Будет обсуждено в следующем посте)

А как насчет недостатков? Плохая сторона ..

  • Сложно настроить.

Итак, теперь вы знаете, что такое Webpack. В следующей публикации этой серии мы рассмотрим настройку Webpack.

Webpack для начинающих - Часть 2