Заученная конфигурация DLL webpack может быть устаревшей

Я написал статью некоторое время назадПодробно объясните запутанные точки знаний в webpack4., я не ожидал получить почти 600 лайков, и я хотел бы поблагодарить вас здесь, старые утюги. В прошлой статье я потратил много времени на размышления о демо и оригинальной иллюстрации, просто чтобы прояснить некоторые концепции.Глядя на ответ в области комментариев, я чувствую, что все же достиг поставленной цели.

Если вы читали какие-то статьи по оптимизации webpack4, динамическая библиотека dll обязательно появится. Он еще свеж в памяти многих новичков своей сложной конфигурацией. Сегодня я шаг за шагом расскажу о настройке dll webpack с точки зрения учащегося и, наконец, предложу идеальное решение.

Содержание этой статьи отличается от большинства статей, объясняющих оптимизацию webpack4., если у вас есть разные мнения, добро пожаловать, чтобы обсудить со мной в области комментариев.

Дружеское напоминание: эта статья не является вводным руководством. Она не будет тратить много чернил на описание базовой конфигурации веб-пакета. Пожалуйста, прочитайте руководство [исходный код] (https://github.com/skychx/webpack_learn/tree/ мастер/оптимизация) есть.

1. Основная концепция: dll на самом деле является кешем

Честно говоря, я только что видел этоdll динамически подключаемая библиотека, я реально обомлел: что это? Почему вы вообще о нем не слышали?

Мне не терпится узнать, я быстро гуглю,ВикипедияСтандартное определение находится в:

Так называемая динамическая ссылка предназначена для преобразования некоторого часто используемого кода в файл DLL.Когда исполняемый файл вызывает функции в файле DLL, операционная система Windows загружает файл DLL в память.Структура самого файла DLL является исполняемым файлом, функция подключается только тогда, когда это необходимо программе. Благодаря динамической компоновке можно значительно сократить ситуацию с непроизводительным расходом памяти.

Увы, ваши чиновники просто не говорят по-человечески.

Я объединяю веб-пакет и перевожу его с точки зрения внешнего интерфейса:

В частности, для веб-пакета он предназначен для того, чтобы заранее упаковать часто используемый, но длительный код времени сборки (например, реагировать, реагировать-дом) и назвать его dll. При последующей упаковке пропустите исходный неупакованный код и используйте dll напрямую. Это сокращает время сборки и увеличивает скорость упаковки веб-пакетов.

Я три минуты смотрел на приведенное выше предложение, какая DLL, какая динамическая библиотека во внешнем мире, разве это не простотайник! Все дело в обмене пространства на время.

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

Давайте сравним DLL и сетевой кеш, с которым часто связывается фронтенд, и это видно из таблицы:

DLL	тайник
1. Упакуйте общедоступный код в виде DLL-файла и сохраните его на жестком диске.	1. Сохраняйте часто используемые файлы на жесткий диск/в память
2. Динамически связать файл DLL при упаковке во второй раз, без переупаковки	2. Чтение кеша напрямую при второй загрузке без повторного запроса
3. Время упаковки сокращается	3. Сокращение времени загрузки

Таким образом, во внешнем мире DLL — это альтернативный кеш.

2. Настройка DLL вручную: я не могу вспомнить так много шагов

В начале не будем заниматься настройкой, давайте представим, если вы позволитеРучное создание кэшей и управление ими,Что бы вы сделали?

Я думаю, что все думают, как правило, так:

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

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

Как правило, когда мы разрабатываем, браузер и протокол http помогают нам инкапсулировать эти операции, нам просто нужно запомнить несколько параметров для настройки параметров; но dll webpack отличается, он требует от нас вручную реализовать 3 вышеуказанных шага, так что это очень скучно + громоздко.

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

Если вам скучно, просто пропустите следующий контент

шаг 1, нам сначала нужно создать файл dll, что эквивалентно сохранению содержимого первого запроса, а затем мы также создаем таблицу сопоставления, чтобы сообщить программе, какой файл мы превратили в dll (это эквивалентноШаг 2):

Сначала мы пишем сценарий упаковки, который создает файл dll, цель которого состоит в том, чтобыreact,react-domУпаковано в файл dll:

// 文件目录：configs/webpack.dll.js
// 代码太长可以不看

'use strict';

const path = require('path');
const webpack = require('webpack');

module.exports = {
    mode: 'production',
    entry: {
        react: ['react', 'react-dom'],
    },
    // 这个是输出 dll 文件
    output: {
        path: path.resolve(__dirname, '../dll'),
        filename: '_dll_[name].js',
        library: '_dll_[name]',
    },
    // 这个是输出映射表
    plugins: [
        new webpack.DllPlugin({ 
            name: '_dll_[name]', // name === output.library
            path: path.resolve(__dirname, '../dll/[name].manifest.json'),
        })
    ]
};

Скрипт упаковки написан, мы должны его запустить, верно? Итак, мы пишем скрипт для запускаpackage.jsonизscriptsтег, поэтому мы запускаемnpm run build:dllВы можете упаковать файл dll:

// package.json

{
  "scripts": {
    "build:dll": "webpack --config configs/webpack.dll.js",
  },
}

Шаг 3, линковка dll-файла, то есть dll-файла, который сообщает вебпаку хит, и конфигурации тоже много:

// 文件目录：configs/webpack.common.js
// 代码太长可以不看

const path = require('path');
const AddAssetHtmlPlugin = require('add-asset-html-webpack-plugin'); // 顾名思义，把资源加到 html 里，那这个插件把 dll 加入到 index.html 里
const webpack = require('webpack');
module.exports = {
  // ......
  plugins: [
    new webpack.DllReferencePlugin({
      // 注意: DllReferencePlugin 的 context 必须和 package.json 的同级目录，要不然会链接失败
      context: path.resolve(__dirname, '../'),
      manifest: path.resolve(__dirname, '../dll/react.manifest.json'),
    }),
    new AddAssetHtmlPlugin({
      filepath: path.resolve(__dirname, '../dll/_dll_react.js'),
    }),
  ]
}

Чтобы сократить время вторичной упаковки некоторых больших библиотек, мы написали кучу конфигурационных кодов в 3 файла, и мы были осторожны, ходили по тонкому льду, и, возможно, ссылка не удалась из-за проблем со скоупом (да, это я) . Настройка dll принесет огромную психологическую тень.Есть ли другой способ уменьшить нашу умственную нагрузку?

3. AutoDllPlugin: избавьте себя от необходимости конфигурировать

В разделе 2 ябезумно уговорили бросить, просто чтобы представить этот плагин:autodll-webpack-plugin, этот плагин объединяет 3 вышеуказанных фрагмента кода вместе, давайте избавимся от громоздкой конфигурации, давайте посмотрим, как ее использовать:

// 文件目录：configs/webpack.common.js

const path = require('path');
const AutoDllPlugin = require('autodll-webpack-plugin'); // 第 1 步：引入 DLL 自动链接库插件

module.exports = {
  // ......
  plugins: [
        // 第 2 步：配置要打包为 dll 的文件
        new AutoDllPlugin({
            inject: true, // 设为 true 就把 DLL bundles 插到 index.html 里
            filename: '[name].dll.js',
            context: path.resolve(__dirname, '../'), // AutoDllPlugin 的 context 必须和 package.json 的同级目录，要不然会链接失败
            entry: {
                react: [
                    'react',
                    'react-dom'
                ]
            }
        })
  ]
}

autodll-webpack-pluginКак использовать и другие веб-пакетыpluginМетод использования очень похож.По сравнению с методом ручного импорта dll он намного проще.Тем более этот плагин раньше использовался vue-cli,и качество относительно стабильное.Можно смело им пользоваться.

4. Откажитесь от DLL: официальный выбор Vue и React

Раздел 3 я сказалautodll-webpack-pluginРаньше он использовался vue-cli, значит, сейчас не используется? Есть ошибка? Это действительно не так.

При изучении веб-пакета, чтобы изучить конфигурацию веб-пакета отличных фреймворков в отрасли, я специально просмотрел исходный код vue-cli и create-react-app, но не нашел никаких следов конфигурации dll.

Это очень странно.Я до этого листал какой-то исходник nuxt.js 1.0, и в нем есть код настройки dll.По логике вещей, он должен быть и у vue-cli.Я догадался, что в каком-то апгрейде поставили dll. Итак, я начал искать запись фиксации и, конечно же, нашел ее:

В черно-белом варианте опция удаления DLL четко написана тремя большими символами.

какова причина? на этоissueРию Юйси объяснила причину удаления:

dll option will be removed. Webpack 4 should provide good enough perf and the cost of maintaining DLL mode inside Vue CLI is no longer justified.

Конфигурация dll будет удалена, поскольку производительность упаковки Webpack 4 достаточно хороша, и нет необходимости в дальнейшем обслуживании dll в Vue CLI.

Так же и в этомPRАналогичное объяснение дано в create-реагировать-приложение:webpack 4 имеет лучшую производительность упаковки, чем dll.

Итак, если проект находится на веб-пакете 4, от повторного использования dll особой пользы не будет. Я попробовал код реального проекта.Добавление dll может дать улучшение скорости на 1-2 секунды, что можно сказать незначительно для общего времени упаковки.

Vue и React официально 2018 больше не используют dll, теперь 2019 год почти закончился, так что скажитеТо, что я сказал выше, бесполезно, не нужно учиться, чувствуете ли вы облегчение (сумасшедшие намеки вроде лайков)?

5. Плагины лучше, чем DLL

dll ускорение не очевидно, есть ли лучшая альтернатива? существуетAutoDllPluginВ README.md нам было рекомендованоHardSourceWebpackPlugin, начальная конфигурация проще и требует всего одну строку кода:

const HardSourceWebpackPlugin = require('hard-source-webpack-plugin');

module.exports = {
  // ......
  plugins: [
    new HardSourceWebpackPlugin() // <- 直接加入这行代码就行
  ]
}

Насколько заметно ускорение работы этого плагина? Я протестировал пример кода из этой статьи.На следующем рисунке показано нормальное время упаковки, около 900 мс:

После добавления оптимизации dll время упаковки составляет 507 мс, что сокращается примерно на 400 мс:

Используя только HardSourceWebpackPlugin, время упаковки снова сократилось до 253 мс:

см. связанныеДокументация, вроде бы эта технология прямо заложена в webpack 5 и работает из коробки. Итак, хотя вам не нужно изучать конфигурацию dll, ноwebpack 5 is coming......

6. Пишите в конце

Эта статья вряд ли является учебным пособием, а скорее отчетом о моем процессе изучения веб-пакета. Если честно, я вручную настраиваю dll и чувствую, что вполне нб, и могу настроить такую сложную конфигурацию.

когда я нашелautodll-webpack-plugin, и обнаружил, что dll заброшен, на самом деле я был немного разочарован, я чувствовал, что мои предыдущие усилия были потрачены впустую, и я ничего не мог поделать.学不动идея. Но когда я тщательно обдумал принцип dll, то обнаружил, что это всего лишь вопрос времени, и место было разменено на время, но конфигурация была немного сложнее.

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

7. Рекомендуемое чтение

Мы все знакомы с протоколом HTTP, так что знаете ли вы ямки, написанные в спецификации HTTP?Эти темные ямы в HTTPможет понять
Обязательно для собеседования! 5 самых запутанных знаний в webpackНаггетсы набрали почти 800 лайков и простыми словами представили несколько концепций Webpack, которые лучше читать вместе с этой статьей.
официальная документация по веб-пакету
autodll-webpack-plugin
HardSourceWebpackPlugin

Напоследок хочу порекомендовать свой личный паблик «Лаборатория яиц в панировке». Обычно я делюсь некоторыми фронтенд-технологиями и контентом для анализа данных. Если вам интересно, то можете обратить внимание на: