Краткое изложение основ Webpack 4 от Шона Ларкина (Часть 2 из 4: Webpack с нуля)

Самоучитель JL # 15

Серия [Самоучитель JL]

[Net Ninja] JS Regular Expressions
[Net Ninja] Vue JS2 (Part1, Part2, Part3)
[Net Ninja] Vuex
[Net Ninja] Python3 (Part1, Part2, Part3)
[Net Ninja] Django (Part1, Part2, Part3)
[Net Ninja] Sass (Part1, Part2)
[Sean Larkin] Webpack4 (Part1, Part2(current), Part3, Part4)

🌲 Это вторая часть моего обзора Основы Webpack 4 Шона Ларкина на FrontendMasters. Перейти на страницу GitHub можно здесь.

[2. Webpack from Scratch]
    2-1. Using Webpack for the First Time
    2-2. Ading NPM Scripts for Environment Builds
    2-3. Setting Up Debugging
    2-4. Coding Your First Module
    2-5. Adding Watch Mode
    2-6. ES Module (ESM) Syntax
    2-7. CommonJS Expert
    2-8. CommonJS Named Exports
    2-9. Tree Shaking
    2-10. Webpack Bundle Walkthrough

[2–1. Первое использование Webpack]

Шаг 1

Посетите страницу GitHub для этого курса.
Войдите в GitHub и создайте репозиторий.
Клонируйте вилку. Для меня это следующее:

$ git clone https://github.com/hlim18/webpack-workshop-2018.git

›По умолчанию вы будете в главной ветке.

Шаг 2

В каталоге, в котором вы клонировали репозиторий, запустите «git fetch --all». Я получил следующее сообщение об ошибке:

Fetching origin
remote: Repository not found.

Чтобы решить эту проблему, я погуглил и нашел это на StackOverflow.

# Способ 1

При запуске «git config --get remote.origin.fetch» должен отображаться «+refs/heads/*:refs/remotes/origin/*». (Подстановочный знак *, конечно, означает все, что находится под этим путем.)

Я понял это правильно. Так что для меня это не было проблемой.

# Способ 2

Удалите исходный пульт с помощью «git remote rm origin» и воссоздайте с помощью «git remote add origin <git uri>».

После этого я запустил «git fetch --all», и это сработало!

Шаг 3

Переместите в папку «webpack -shops-2018»: cd webpack-workshop-2018.
Перейти в стартовую ветку

$ git checkout feature/01-fem-first-script

›Если командная строка запущена успешно, вы получите следующее сообщение:

Branch 'feature/01-fem-first-script' set up to track remote branch 'feature/01-fem-first-script' from 'origin'.
Switched to a new branch 'feature/01-fem-first-script'

Шаг 4

Запустите npm install или yarn, чтобы установить зависимости. Добавьте следующий текст в файл package.json, если он не включен в файл.

{
  "scripts": {
    "webpack": "webpack"
}

Запустите npm run webpack, чтобы запустить первый сценарий npm. Кстати, я получил следующее сообщение об ошибке:

TypeError: Cannot read property 'properties' of undefined

Судя по всему, с такой же проблемой столкнулись несколько человек (GitHub). Похоже, возникла проблема с [email protected] выпущен 25 сентября 2018 г..

Я удалил [email protected] и установил [email protected].

npm uninstall webpack --save
npm install [email protected] --save

›Проверьте установленную версию Webpack: npm list webpack или npm show webpack version.

Если выполнение npm run webpack выполнено успешно, вы получите следующее сообщение:

[2–2. Добавление сценариев NPM для сборок среды]

Теперь мы можем запускать Webpack из наших скриптов. У нас есть доступ для его запуска. Кстати, мы можем сделать еще один шаг. NPM обладает этой замечательной возможностью для создания скриптов (это началось с NPM. Yarn также поддерживает его).

Шаг 1

Добавьте сценарий разработчика в файл package.json:

{
  "scripts": {
    "webpack": "webpack",
    "dev": "npm run webpack -- --mode development"
}

›Синтаксис« -- »означает перенос следующих аргументов в исходные команды

›› Теперь, когда вы вносите изменения, другие команды будут изменены по вашему желанию.

Шаг 2

Запустите Webpack в режиме разработки: npm run dev

Добавьте рабочий сценарий в файл package.json:

{
  "scripts": {
    "webpack": "webpack",
    "dev": "npm run webpack -- --mode development",
    "prod": "npm run webpack -- --mode production"
}

Запустите Webpack в рабочем режиме: npm run prod

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

›› Очень важно подумать о двух разных средах для вашей сборки. Это то, что может позволить вам создавать более быстрые или более оптимизированные сборки.

[2–3. Настройка отладки]

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

Шаг 1

Перейдите в ветку сценария отладки:

$ git checkout feature/03-fem-debug-script --force

В случае успешного выполнения вы увидите следующее сообщение:

Branch 'feature/03-fem-debug-script' set up to track remote branch 'feature/03-fem-debug-script' from 'origin'.
Switched to a new branch 'feature/03-fem-debug-script'

Если терминал сообщает, что у вас есть неустановленные изменения, добавьте в конце «- force»:

$ git checkout feature/03-fem-debug-script --force

Вы можете видеть, что тег «скрипт» теперь выглядит следующим образом:

"scripts": {
  "webpack": "webpack",
  "debug": "node --inspect --debug-brk ./node_modules/webpack/bin/webpack.js",
  "prod": "npm run webpack -- --mode production",
  "dev": "npm run webpack -- --mode development",
  "prod:debug": "npm run debug -- --mode production",
  "dev:debug": "npm run debug -- --mode development",
},

Если вы хотите отладить приложение Node или сценарий Node, вы можете сделать это, просто запустив Node и передав пару аргументов.

Шаг 2

Добавьте сценарий отладки в файл package.json:

"scripts": {
  "webpack": "webpack",
  "debug": "node --inspect --debug-brk ./node_modules/webpack/bin/webpack.js",
  "prod": "npm run webpack -- --mode production",
  "dev": "npm run webpack -- --mode development",
  "prod:debug": "npm run debug -- --mode production",
  "dev:debug": "npm run debug -- --mode development",
  "debugthis": "node --inspect --inspect-brk ./src/index.js"
},

Запустите npm run debugthis в терминале.

Введите «chrome://inspect» в Chrome.

Нажмите значок Node.js или «проверить»

Вы находитесь внутри Node.js прямо сейчас и остановились в точке останова. Оказывается, у нас нет никакого кода. Если вы написали оператор отладчика, вы действительно можете взломать его и посмотреть, как этот код выглядит.

Шаг 3

Запустите инспектор отладки в модуле основного узла Webpack: npm run debug

Обновите «node --inspect - debug-brk» на «node --inspect-brk».

"scripts": {
  "webpack": "webpack",
  "debug": "node --inspect-brk ./node_modules/webpack/bin/webpack.js",
  "prod": "npm run webpack -- --mode production",
  "dev": "npm run webpack -- --mode development",
  "prod:debug": "npm run debug -- --mode production",
  "dev:debug": "npm run debug -- --mode development",
  "debugthis": "node --inspect --inspect-brk ./src/index.js"
},

›Проблема устранена!

Теперь вы буквально в режиме Webpack отладки.

›Cmd/Ctrl + P позволяет выбрать файл, пока вы находитесь в состоянии.

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

[2–4. Кодирование вашего первого модуля]

Шаг 1

Создайте новый файл с именем «nav.js» в папке «src».

WEBPACK-WORKSHOP-2018 (project name)
- src
   |-- index.js
   |-- nav.js
- package.json

Начнем с «export defaults», чтобы понять, как его использовать с точки зрения потребления.

[src > nav.js]
export default "nav";
-----------------------------------
[src > index.js]
import nav from "./nav";
console.log(nav);

›« Относительный путь »был заимствован из CommonJS.

Шаг 2

Запустите npm run prod в терминале.

›Вы могли бы заметить файл main.js в папке« dist ». По умолчанию «dist» - это место, куда будут помещены ваши созданные веб-ресурсы.

WEBPACK-WORKSHOP-2018 (project name)
- dist
   |-- main.js
- src
   |-- index.js
   |-- nav.js
- package.json

Запустите node ./dist/main.js в терминале. Вы получите следующее:

nav

›Мы взяли два модуля и соединили их. Теперь его функционал выполнен так же, как мы писали модули.

[2–5. Добавление режима просмотра]

Вместо того, чтобы заставлять людей запускать «npm run prod», добавьте флаг наблюдения, используя «режим просмотра» Webpack.

Шаг 1

Добавьте --watch в сценарий «dev»

"scripts": {
  "webpack": "webpack",
  "debug": "node --inspect --debug-brk ./node_modules/webpack/bin/webpack.js",
  "prod": "npm run webpack -- --mode production",
  "dev": "npm run webpack -- --mode development --watch",
  "prod:debug": "npm run debug -- --mode production",
  "dev:debug": "npm run debug -- --mode development",
  "debugthis": "node --inspect --inspect-brk ./src/index.js"
},

Выполните следующее, чтобы Webpack отслеживал изменения в ваших файлах: npm run dev.

›Процесс не завершается, а просто отображается отзыв.

Шаг 2

Что, если мы изменим текущий код export default “nav”; в файле nav.js на следующий: export default () => “nav”;?

›Поскольку новый код - это функция, возвращающая строку« nav », мы должны вызвать« nav », чтобы вернуть строку в файл index.js.

[src > nav.js]
export default () => “nav”;
-----------------------------------
[src > index.js]
import nav from "./nav";
console.log(nav());

›По мере внесения изменений Webpack постепенно компилирует данные. Он меняет все модули, с которыми вы работаете.

[2–6. Синтаксис модуля ES (ESM)]

Шаг 1

Создайте новый файл с именем «footer.js» в папке «src».

WEBPACK-WORKSHOP-2018 (project name)
- src
   |-- footer.js
   |-- index.js
   |-- nav.js
- package.json

Здесь мы можем использовать синтаксис деструктуризации ES6.

Разрушение просто подразумевает разбиение сложной структуры на более простые части (Средний).

[src > nav.js]
export default () => “nav”;
-----------------------------------
[src > footer.js]
export const top = "top";
export const bottom = "bottom";
-----------------------------------
[src > index.js]
import nav from "./nav";
import {top, bottom} from "./footer";
console.log(nav(), top, bottom);

Запустите npm run prod в терминале.

*** График зависимостей в Webpack

index.js: точка входа
nav.js и footer.js: файлы, от которых зависит index.js.

Шаг 2

Запустите node ./dist/main.js в терминале. Вы получите следующее:

nav top bottom

[2–7. CommonJS Expert]

По состоянию на 29 июня 2018 г. в React по-прежнему использовался CommonJS. У React есть собственная модульная система внутри. Давайте посмотрим, как мы можем использовать модули CommonJS.

Выполните следующее, чтобы Webpack отслеживал изменения ваших файлов: npm run dev.

Для CommonJS формат примерно такой же. Давайте создадим файл button.js.

WEBPACK-WORKSHOP-2018 (project name)
- src
   |-- button.js
   |-- footer.js
   |-- index.js
   |-- nav.js
- package.json

У нас есть два варианта. Мы можем выполнить «экспорт по умолчанию» или «именованный экспорт».

[src > button.js]
// take a str, the button label and return an element
module.exports = (buttonName) => {
  return 'Button: ${buttonNAme}';
};

В Webpack нельзя использовать синтаксис CommonJS и ES в одном файле (нельзя использовать export, а затем default exports или module.exports). Шон Ларкин обычно использует синтаксис ES M odule (ESM) на верхнем уровне.

Webpack поддерживает выражение require() CommonJS (Официальный веб-сайт Webpack). Но мы фактически прервали поддержку использования обоих и точную работу с правильными циклическими зависимостями и легким связыванием.

Поскольку мы знаем, что это экспорт по умолчанию, мы можем добавить следующий полужирный код:

[src > index.js]
import nav from "./nav";
import {top, bottom} from "./footer";
import makeButton from "./button";
console.log(nav(), top, bottom, makeButton("My first button"));

Шон Ларкин настоятельно рекомендует по возможности не использовать CommonJS.

Иногда вы можете использовать это, даже не подозревая об этом. Существуют такие инструменты, как Babel и TypeScript, которые по умолчанию безопасно конвертируют ваш ESM в CommonJS за кулисами, а затем передают его в Webpack. Но Webpack поддерживает ESM "из коробки", и именно это делает возможным встряхивание дерева и все оптимизации.

Встряхивание дерева - это термин, обычно используемый в контексте JavaScript для устранения мертвого кода. Он основан на статической структуре синтаксиса модуля ES2015, т.е. import и export (Webpack).

Устранение мертвого кода подходит к проблеме с противоположной стороны. Он анализирует ваш код после того, как он был объединен, и удаляет код, который не используется в вашем приложении ( Средний ).

[2–8. Именованный экспорт CommonJS]

Шаг 1

Создайте файл button-styles.js.

WEBPACK-WORKSHOP-2018 (project name)
- src
   |-- button-styles.js
   |-- button.js
   |-- footer.js
   |-- index.js
   |-- nav.js
- package.json

Давайте добавим три именованных экспорта, которые мы могли бы извлечь.

[src > button-styles.js]
const red = "color: red";
const blue = "color: blue";
const makeColorStyle = (color) => `color: ${color}`;

Шон Ларкин использует prettier, самоуверенный форматтер кода.

Шаг 2

Давайте экспортируем значения.

[src > button-styles.js]
const red = "color: red";
const blue = "color: blue";
const makeColorStyle = (color) => `color: ${color}`;
exports.red = red;
exports.blue = blue;
exports.makeColorStyle = makeColorStyle;

Поскольку Webpack работает на Node.js, весь код Webpack - CommonJS. Таким образом, оставлять exports внизу файла не требуется. Но Шон Ларкин рекомендует делать это.

Шаг 2–1

Давайте проведем рефакторинг кода в файле footer.js. В настоящее время файл выглядит следующим образом:

[src > footer.js]
export const top = "top";
export const bottom = "bottom";

Но давайте переместим exports в конец файла.

[src > footer.js]
const top = "top";
const bottom = "bottom";
export { top, bottom };

Если при запуске Webpack в режиме разработки (npm run dev) вы неправильно написали имя экспорта, например «дно», вы получите следующее сообщение:

›Когда это ESM, Webpack выдает предупреждение о том, что Webpack не может найти экспорт, используемый в точке входа. Это была новая функция, добавленная в Webpack 4.

Шаг 2–2

Давайте проведем рефакторинг кода в файле button.js. В настоящее время файл выглядит следующим образом:

[src > button.js]
// take a str, the button label and return an element
module.exports = (buttonName) => {
  return 'Button: ${buttonName}';
};

Переместим экспорт в конец.

[src > button.js]
// take a str, the button label and return an element
const makeButton = (buttonName) => {
  return 'Button: ${buttonName}';
};
module.exports = makeButton;

Шаг 3

Шон Ларкин очень увлечен добавлением js.docs в исходный код Webpack, потому что мы можем получить полную проверку TypeScript в нашем приложении, просто добавив js.docs. Таким образом, утилиты работают лучше, если имеют именованные параметры, а не просто «модуль» или «модуль.exports».

// type "/** */" and press "enter" in the middle
/**
 * @param {string} buttonName
 * @returns {Element}
*/

Наконец, давайте воспользуемся файлом CommonJS и его отдельными экспортированными файлами.

[src > index.js]
import nav from "./nav";
import {top, bottom} from "./footer";
import makeButton from "./button";
import {makeColorStyle} from "./button-styles";
console.log(
  nav(),
  top,
  bottom,
  makeButton("My first button!"),
  makeColorStyle("cyan")
);

›Вы должны извлекать только то, что используете, потому что Webpack использует эту информацию, чтобы объединить только то, что вы используете.

[2–9. Tree Shaking]

WEBPACK-WORKSHOP-2018 (project name)
- dist
   |-- main.js
- src
   |-- button-styles.js
   |-- button.js
   |-- index.js
- package.json

Шаг 1

Давайте снова объединим этот код в производственную среду. Запустите npm run prod, чтобы увидеть, что произойдет.

Этот запрос на вытягивание показывает различия между CommonJS экспортом и экспортом ESM.

ПЕРЕД: CommonJS экспортирует

[src > button-styles.js]
const red = "color: red";
const blue = "color: blue";
const makeColorStyle = (color) => `color: ${color}`;
exports.red = red;
exports.blue = blue;
exports.makeColorStyle = makeColorStyle;
-----------------------------------
[src > button.js]
// take a str, the button label and return an element
const makeButton = (buttonName) => {
  return 'Button: ${buttonName}';
};
module.exports = makeButton;

ПОСЛЕ: экспорт ESM.

[src > button-styles.js]
const red = "color: red";
const blue = "color: blue";
const makeColorStyle = (color) => `color: ${color}`;
exports {red, blue, makeColorStyle}
-----------------------------------
[src > button.js]
// take a str, the button label and return an element
const makeButton = (buttonName) => {
  return 'Button: ${buttonName}';
};
export default makeButton;

›Если вы выполните поиск« красный »или« синий »в файле main.js, мы сможем его найти. Причина в том, что мы используем экспорт CommonJS, а встряхивание дерева НЕ работает с экспортом CommonJS.

›Если вы выполните поиск« красный »или« синий »в файле main.js, мы НЕ сможем их найти. Это то, что называется «устранением мертвого кода» или «встряхиванием дерева».

Встряхивание дерева - термин, обычно используемый в контексте JavaScript для удаления мертвого кода. Он основан на «статической структуре синтаксиса модуля ES2015, т.е. import и export »( Webpack ).

Устранение мертвого кода подходит к проблеме с противоположной стороны. Он анализирует ваш код после того, как он был объединен, и удаляет код, который не используется в вашем приложении ( Средний ).

Доступно для просмотра полного кода с подсветкой синтаксиса на GitHubGist.

Вы также можете перейти в ветку 031-all-module-types, если чувствуете себя потерянным.

Шаг 2

Давайте добавим нашу первую конфигурацию Webpack. Создайте файл webpack.config.js.

WEBPACK-WORKSHOP-2018 (project name)
- dist
   |-- main.js
- src
   |-- button-styles.js
   |-- button.js
   |-- footer.js
   |-- index.js
   |-- nav.js
- package.json
- webpack.config.js

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

[webpack.config.js]
module.exports = {};

Шаг 3

Запустить webpack в рабочем режиме: npm run prod

Шон Ларкин использует yarn prod, который является альтернативой работе через npm с: npm run prod

Код (module.exports = {};) ничего не нарушает при запуске Webpack, потому что Webpack применяет значения по умолчанию после того, как требует конфигурации. Все это позволяет вам переопределить любое поведение по умолчанию.

Шаг 4

Давайте рассмотрим выводимый код.

[webpack.config.js]
module.exports = {
  mode: "none"
};

›Этот код указывает Webpack объединить его, но не заключать в evals.

Шаг 5

Мы должны запустить код, не передавая ему никаких аргументов. Итак, запустите npm run webpack в терминале.

›Он все еще строится!

[2–10. Пошаговое руководство по Webpack Bundle]

Шаг 1

Давайте посмотрим на файл main.js в папке dist. Вы можете проверить это здесь".

Вверху файла вы видите Я немедленно Я вызвал F функцию E xpression (IIFE)! Давайте посмотрим, где же конец и что в него вкладывается.

В IIFE передаются переменные, называемые «модулями».

(function(modules) { // webpackBootstrap

Однако мы пока не знаем, как это выглядит. Итак, давайте погрузимся в самое дно.

/******/   // Load entry module and return exports
/******/   return __webpack_require__(__webpack_require__.s = 0);
/******/ })
/************************************************************************/

›Окончание бара комментариев! Вот и конец IIFE.

Шаг 2

После окончания комментариев бара начинается массив. Массив заканчивается внизу файла.

/************************************************************************/
/******/ ([
//...
/***/ })
/******/ ]);

Что у нас внутри массива? У нас есть массив IIFE !

И это наш настоящий код!

/******/ ([
/* 0 */
/***/
-----------------------------------
/***/ }),
/* 1 */
/***/
-----------------------------------
/***/ }),
/* 2 */
/***/
-----------------------------------
/***/ }),
/* 3 */
/***/
-----------------------------------
/***/ }),
/* 4 */
/***/

›Есть украшения с идентификаторами, чтобы помочь людям понять, как наш код организован в файле.

Итак, мы получаем массив IIFE, переданных здесь в код (вверху файла).

(function(modules) { // webpackBootstrap

Webpack называет его «Webpack Bootstrap». Некоторые называют это «время выполнения».
Мало кто называет это «Манифестом». Но Шон не рекомендует думать о таком манифесте, потому что это сбивает с толку весь манифест PWA.
Шон Ларкин называет это «кодом времени выполнения», потому что наши внутренние API обычно говорят chunk.hasRuntime.

Шаг 3

Давайте разберемся, что именно делает код в файле, шаг за шагом, начиная с начала файла.

/******/ (function(modules) { // webpackBootstrap
/******/   // The module cache
/******/   var installedModules = {};

Мы пока не знаем, как это работает. Но мы узнаем!

Шаг 3–1.

/******/   // START of the require function
/******/   function __webpack_require__(moduleId) {
/******/     // Check if module is in cache
/******/     if(installedModules[moduleId]) {
/******/       return installedModules[moduleId].exports;
/******/     }

__webpack_require__ принимает параметр moduleId. Когда эта функция вызывается, ей будет передан какой-то идентификатор.
Не путайте .exports с реальной семантикой модуля. Вот как мы заставляем его работать в браузере.
return installedModules[moduleId].exports вернет свойство с именем .exports из того, что находится внутри кеша этого модуля.

/******/     // Create a new module (and put it into the cache)
/******/     var module = installedModules[moduleId] = {
/******/       i: moduleId,
/******/       l: false,
/******/       exports: {}
/******/     };
/******/

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

/******/     // Execute the module function
/******/     modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);

Теперь нам действительно нужно вызвать код, который нам нужен, потому что мы все еще находимся внутри функции require: __webpack_require__.
Мы идем и находим модуль, берем экспорт и передаем другие вещи внутри этого IIFE, потому что наши модели представляют собой массив IIFE.
Мы передаем требуемую функцию. Поэтому, когда модуль использует другие модули, мы предоставляем экспорт по умолчанию или именованный экспорт.

/******/
/******/     // Flag the module as loaded
/******/     module.l = true;

«L» означает, что модуль загружен. По умолчанию установлено значение «false». Но как только он будет выполнен, мы установим значение «true».

/******/
/******/     // Return the exports of the module
/******/     return module.exports;
/******/   } 
/******/   // END of the require function

Мы возвращаем свойство «.exports» из этого синтетического модуля, который мы создаем.

__webpack_require__ функция принимает идентификатор, вызывает модуль, а затем возвращает любой экспорт, если он доступен.

Шаг 3–2.

ESM использует так называемые «живые привязки, функцию, поддерживающую циклические зависимости. Изначально это будет реализовано внутри браузера.

//...
/******/   // define getter function for harmony exports
/******/   __webpack_require__.d = function(exports, name, getter) {
/******/     if(!__webpack_require__.o(exports, name)) {
/******/       Object.defineProperty(exports, name, {
                 enumerable: true,
                 get: getter });
/******/     }
/******/   };

По сути, мы замораживаем объект, поэтому его нельзя переназначить или изменить. Вот почему мы заключаем его в свойство, определяющее объект.

/******/   // define __esModule on exports
/******/   __webpack_require__.r = function(exports) {
/******/     if(typeof Symbol !== 'undefined' && Symbol.toStringTag) {
/******/       Object.defineProperty(
                 exports,
                 Symbol.toStringTag, 
                 { value: 'Module' }
               );
/******/     }
/******/     Object.defineProperty(
               exports,
               '__esModule',
               { value: true }
             );
/******/   };

Это для прерывания CommonJs. CommonJS технически не имеет экспорта по умолчанию. В нем есть модули, которые экспортируют. Итак, что мы делаем, это согласовываем с TypeScript и Babel, чтобы обеспечить единообразие этого шаблона.

Шаг 3–3.

Перейти в конец строки комментариев.

/******/   // Load entry module and return exports
/******/   return __webpack_require__(__webpack_require__.s = 0);
/******/ })
/************************************************************************/

Какой идентификатор проходит? Первый модуль!
Мы выполняем нашу точку входа.

Шаг 3–4.

Подведем итоги.

/******/ (function(modules) { // webpackBootstrap

Модули вызывают здесь эту функцию, что не IFFE:

/* 0 */
/***/ (function(module, __webpack_exports__, __webpack_require__) {
"use strict";
__webpack_require__.r(__webpack_exports__);
/* harmony import */ var _nav__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__(1);
/* harmony import */ var _footer__WEBPACK_IMPORTED_MODULEgit fetch --all_ = __webpack_require__(2);
/* harmony import */ var _button__WEBPACK_IMPORTED_MODULEgit config --get remote.origin.fetch_ = __webpack_require__(3);
/* harmony import */ var _button_styles__WEBPACK_IMPORTED_MODULE+refs/heads/*:refs/remotes/origin/*_ = __webpack_require__(4);

Мы передаем функцию, и она вызывает другие требуемые функции.
Поскольку это разные модули в разных расположениях, у нас разные идентификаторы.
Этот код (в файле main.j s) немного похож на следующий код в файле index.js:

import nav from "./nav";
import {top, bottom} from "./footer";
import makeButton from "./button";
import { makeColorStyle } from "./button-styles";

›__webpack_require__ заменяет операторы require в файле main.js (которые соответствуют операторам import в index. js) с тем, что действительно работает в браузере. И код в файле main.js, и код в файле index.js выполняются и ведут себя одинаково в правильном порядке.

Шаг 4

Код в файле main.js в папке dist - это минимальные накладные расходы, возникающие при использовании Webpack. Но все делается во время сборки. Итак, это единственный исполняемый код, существующий в Webpack. Все остальное - это просто продукт сборки.

Замечательно изучить код в файле, если вы хотите узнать, как все работает. При отладке приятно установить режим «нет», потому что комментарии показывают характеристики кода. Это похоже на использование той же эвристики, которую мы использовали для встряхивания дерева.

Преподаватель класса Шон Ларкин является техническим менеджером программы Microsoft для Microsoft Edge. Шон также является членом основных команд Webpack и Angular.

Его можно найти на GitHub, Codepen, StackOverlfow (CV), LinkedIn, Twitter, Medium (Шон Т. Ларкин) и Frontend Masters. .

›Его страница спроси меня о чем угодно : http://github.com/thelarkinn/ama

Спасибо за прочтение! 💕 Если вам нравится этот пост в блоге, пожалуйста, хлопайте в ладоши👏

Краткое изложение основ Webpack 4 от Шона Ларкина (Часть 2 из 4: Webpack с нуля)

Самоучитель JL # 15

[2–1. Первое использование Webpack]

Шаг 1

Шаг 2

Шаг 3

Шаг 4

[2–2. Добавление сценариев NPM для сборок среды]

Шаг 1

Шаг 2

[2–3. Настройка отладки]

Шаг 1

Шаг 2

Шаг 3

[2–4. Кодирование вашего первого модуля]

Шаг 1

Шаг 2

[2–5. Добавление режима просмотра]

Шаг 1

Шаг 2

[2–6. Синтаксис модуля ES (ESM)]

Шаг 1

Шаг 2

[2–7. CommonJS Expert]

[2–8. Именованный экспорт CommonJS]

Шаг 1

Шаг 2

Шаг 2–1

Шаг 2–2

Шаг 3

[2–9. Tree Shaking]

Шаг 1

Шаг 2

Шаг 3

Шаг 4

Шаг 5

[2–10. Пошаговое руководство по Webpack Bundle]

Шаг 1

Шаг 2

Шаг 3

Шаг 3–1.

Шаг 3–2.

Шаг 3–3.

Шаг 3–4.

Шаг 4

Вопросы по теме