Если зависимости каждого модуля в проекте рассматриваются как дерево, то запись является корнем дерева зависимостей.
Эти зависимые модули будут инкапсулированы в чанк при упаковке. Так что же такое чанк?
Чанк буквально означает блок кода, который в Webpack можно понимать как несколько модулей, которые были абстрагированы и упакованы. Это похоже на пакет файлов, содержащий множество файлов. Каждый модуль Webpack добавляет слой упаковки снаружи, образуя фрагмент:
В зависимости от конкретной конфигурации при упаковке проекта могут быть созданы один или несколько фрагментов.
В проекте можно определить несколько записей, и каждая запись будет генерировать ресурс результата.
Например, в нашем проекте есть две записи: src/index.js и src/lib.js . В обычных обстоятельствах dist/index.js и dist/lib.js
В некоторых особых случаях одна запись может генерировать несколько фрагментов и, в конечном итоге, несколько
Параметры:
модуля.exports = {
запись:'./src/index.js', //Указывает файл записи, то есть вход в наш проект из index.js}; ①Пример типа записи
| , | означающий | строку |
|---|---|---|
| ' | ./app/entry' | Путь к файлу записи модуль, который может быть |
| массивом | относительных путей['./app/entry1', './app/entry2'] | Путь к файлу входного модуля, который может быть |
| объектом | относительного пути{ a: './app/entry- a', b: ['./app/entry-b1', './app/entry-b2']} | При настройке нескольких записей каждая запись генерирует чанк, |
если это тип массива, при использовании с выходными данными. элемент конфигурации библиотеки, только последний в массиве. Модуль файла записи будет экспортирован.
② Имя чанка.
Webpack присваивает имя каждому сгенерированному чану. Имя чанка связано с конфигурацией записи:
③Динамика конфигурации записи.
Если в проекте несколько страниц, вам необходимо настроить запись для каждой страницы, но количество этих страниц может продолжать расти, тогда конфигурация записи. на него будут влиять другие факторы, и его нельзя записать как статическое значение. Решение состоит в том, чтобы установить Entry в функцию для динамического возврата конфигурации, упомянутой выше. Код выглядит следующим образом:
// Синхронный ввод функции: () => {.
возвращаться {
а:'./страницы/а',
б:'./страницы/б',
}
};
// Запись асинхронной функции: () => {
вернуть новое обещание((решить)=>{
решать({
а:'./страницы/а',
б:'./страницы/б',
});
});
}; Параметр: context
Webpack будет использовать context в качестве корневого каталога при поиске файлов с относительными путями . По умолчанию контекстом является текущий рабочий каталог, в котором запущен Webpack. Если вы хотите изменить конфигурацию контекста по умолчанию, вы можете установить ее в файле конфигурации следующим образом:
Module.exports = {
контекст: path.resolve(__dirname, 'app')
} Обратите внимание, что контекст должен быть строкой абсолютного пути.
Кроме того, вы также можете установить, указав параметр webpack --context при запуске Webpack.
Использование: entry:string|Array<string>
1. Сокращенный синтаксис
webpack.config.js
//Поскольку он один, его можно сократить как:
модуль.экспорт = {
запись: './main.js'
} Приведенная выше конфигурация записи на самом деле записывается в виде следующей аббревиатуры:
mod.exports = {;
вход: {
основной: './main.js'
}
} 2. Синтаксис массива
mod.exports = {;
вход: {
main:['./main.js','./main2.js']
}
}; Функция передачи массива заключается в предварительном объединении нескольких ресурсов. При упаковке Webpack будет использовать последний элемент массива в качестве фактического пути записи.
При использовании строки или массива для определения одной записи нет. способ изменить имя чанка, может быть только «основным» по умолчанию.
Использование: entry: {[entryChunkName: string]: string|Array}
Синтаксис объекта
модуль.exports = {
вход: {
приложение: './src/app.js',
поставщики: './src/vendors.js'
}
}; Это будет более громоздко. Однако это наиболее расширяемый способ определения точек входа в приложении.
«Расширяемая конфигурация веб-пакета» : можно использовать повторно и комбинировать с другими конфигурациями. Это популярный метод отделения задач от среды, цели сборки и среды выполнения. Затем объедините их с помощью специализированных инструментов, таких как webpack-merge.
1. Одностраничные приложения
, будь то платформы, библиотеки или модули на каждой странице, ссылаются на одну точку входа app.js Преимущество этого в том, что будет сгенерирован только один JS-файл и зависимости будут понятны .
модуль.экспорт = {
запись: './src/app.js'
}; У этого подхода есть и недостатки, то есть все модули упаковываются вместе, когда масштаб приложения увеличивается до определенного уровня, генерируемый объем ресурсов будет слишком большим, что снизит скорость отрисовки страницы пользователя
по умолчанию. конфигурации Webpack, когда размер пакета превышает 250 КБ (до сжатия), пакет будет считаться слишком большим, и во время упаковки появится предупреждение, как показано на рисунке:
2. Отделите стороннюю библиотеку (поставщика).
Чтобы решить вышеуказанную проблему, вы можете извлечь стороннюю библиотеку (поставщик).
В Webpack термин «поставщик» обычно относится к третьим сторонам, таким как библиотеки . и фреймворки, используемые в проекте. Bundle
mod.exports = {.
вход: {
приложение: './src/app.js',
поставщики: ['реагировать','реагировать-дом','реагировать-маршрутизатор'],
}
}; На примере приложения мы добавили новый вход с именем чанка vendor , а сторонние модули, от которых зависит проект, мы не задали в виде массива.
Путь входа для вендора мы не задавали
.Что делать с Webpack?
В настоящее время мы можем использовать CommonsChunkPlugin (от CommonsChunkPlugin отказались после Webpack 4, вы можете использовать оптимизацию.splitChunks) для извлечения общих модулей из двух частей приложения и поставщика.
В этой конфигурации пакет, сгенерированный app.js, будет только. содержит Бизнес-модуль и сторонние модули, от которых он зависит, будут извлечены для создания нового пакета, что также достигает нашей цели по извлечению поставщика.
Поскольку поставщик содержит только сторонние модули, эта часть не будет часто меняться. Таким образом, можно эффективно использовать кэширование на стороне клиента, что ускорит общую скорость рендеринга, когда пользователь впоследствии запрашивает страницу.
CommonsChunkPlugin в основном используется для извлечения сторонних библиотек и общедоступных модулей, чтобы предотвратить слишком большой размер файлов пакета, загружаемых на первом экране, или файлов пакета, загружаемых по требованию, что приводит к длительному времени загрузки.
3. Многостраничное приложение.
Для сценариев многостраничных приложений, чтобы максимально уменьшить размер ресурсов, мы надеемся, что каждая страница загружает только свою необходимую логику, а не упаковывает все страницы в один и тот же пакет. Поэтому каждой странице нужен независимый пакет . В этом случае для достижения этой цели мы используем несколько записей. См. следующий пример:
module.exports = {
вход: {
pageOne: './src/pageOne/index.js',
pageTwo: './src/pageTwo/index.js',
pageThree: './src/pageThree/index.js'
}
}; Приведенная выше конфигурация сообщает веб-пакету, что ему нужны 3 независимых и разделенных графа зависимостей. На данный момент запись и страница находятся в взаимно однозначном соответствии, чтобы каждый HTML мог загружать необходимые ему модули, пока он вводит. свой собственный JS.