Анализируйте и оптимизируйте проекты с помощью webpack

Войдя в компанию, он взял на себя большой проект, оставленный его предшественниками. К счастью, у всего проекта есть полные документы о функциях продукта, а потому, что проект слишком большой и старый. Он содержит много проблем, таких как медленная упаковка и слишком много избыточных файлов. Если вы хотите решить эти проблемы быстро, если вы хотите полностью реорганизовать функцию, цена будет слишком высока. По одному, временные затраты относительно велики. Поэтому в этой статье мы расскажем, как я сотрудничаю с webpack для пошагового анализа и оптимизации проекта.
В то же время я инкапсулировалwebpack-unused-files, используется для поиска избыточных файлов в проекте, добро пожаловать, чтобы попробовать и пометить
Оригинальная ссылка

вопрос

Сначала давайте в общих чертах посмотрим, какие проблемы у нас есть, а потом пошагово решим их.

• Проект часто модифицируется и слишком много избыточных файлов
• Некоторыми сторонними зависимостями злоупотребляют, и я хочу их удалить, но не знаю, в каком именно файле. или бесполезный, но оставленный в package.json,
• Проект огромен, упакованный результат слишком велик, а время слишком велико

Удалить лишние файлы

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

1. Получить все файлы, от которых зависит проект

Давайте посмотрим на формат выходного файла webpack:

{
  ...
  chunks: [{
    name: 'chunk-name',
    modules: [
      // 每个chunk中所有的依赖文件
    ]
  }]
  ...
}

Итак, по этому stats.json мы можем получить все файлы проекта во всем проекте:

/**
 * 查询依赖的模块
 */
function findSrcModules () {
  return new Promise((resolve, reject) => {
    fs.readFile(statPath, (err, data) => {
      if (err) return
      const json = JSON.parse(data)
      const assetsList = json.chunks
      let ret = []
      // 拿到所有chunk的所有依赖文件
      assetsList.forEach(chunk => {
        const modules = chunk.modules.map(item => item.name)
        ret = ret.concat(modules)
      })
      // 去除node_modules中的文件
      ret = ret.filter(item => item.indexOf('node_modules') < 0)
      resolve(ret)
    })
  })
}

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

2. Получить все файлы в проекте

С помощью glob мы можем получить все файлы:

function getAllFilesInSrc () {
  const pattern = './src/**'

  return new Promise((resolve, reject) => {
    glob(pattern, {
      nodir: true
    }, (err, files) => {
      const ret = files.map(item => {
        return item.replace('./src', '.')
      })
      resolve(ret)
    })
  })
}

3. Сравните два файловых массива, а затем выполните такие операции, как удаление:

При сравнении двух массивов файлы, которые не отображаются в зависимостях, являются избыточными файлами. Мы можем удалить одним щелчком мыши

findSrcModules().then(ret => {
  getAllFilesInSrc().then(allFiles => {
    const unUsed = allFiles.filter(item => {
      return ret.indexOf(item) < 0
    })
    const join = p => path.join('./src', p)

    unUsed.forEach(file => {
      shelljs.rm(join(file))
    })
  })
})

Анализ сторонних зависимостей

По идее вышеперечисленных избыточных файлов мы можем иметь дело и со сторонними зависимостями.Общая идея такова

1. Получить все зависимости, включая node_modules
2. Сократите и дедуплицируйте имя файла. получить все зависимости
3. Сравните с package.json, чтобы получить неиспользуемые зависимости
4. Проанализируйте результаты сравнения и сохраните зависимости, которые вы не хотите использовать.
5. Снова найдите stat.json, найдите поле reson зависимости, получите ссылку на зависимость и выведите
6. Вручную заменить или удалить зависимости

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

Эта функция будет обновлена ​​доwebpack-unused-filesвходить.

Оптимизированный размер упаковки

Что шокирует, так это то, что весь проект имеет размер почти 20M после того, как он был упакован по разным причинам! Хотя это не проект TO C, а код разделен и лениво загружается для страницы, как «квалифицированный внешний интерфейс», это явление необходимо изменить (да!). Как начать? Слишком сложно просматривать код один за другим, чтобы увидеть, на какие большие зависимости мы все ссылаемся, и какие проекты слишком велики. Посмотрим, предоставит ли webpack какие-либо решения:

1. Показать результаты упаковки

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

webpack --display-modules --sort-modules-by size

Результат выглядит следующим образом:

Мы можем быстро найти самые популярные js-файлы или сторонние зависимости и решить, что с ними делать.

2. Зависимость визуального анализа

webpack предоставляет функцию для вывода всех упакованных файлов зависимостей и связей в формате json:

webpack --profile --json > stats.json

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

webpack analyse

webpack chart

3. План оптимизации

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

• CommonsChunkPlugin извлекает общий код
• dll-плагин упаковывает большие файлы отдельно и кэширует их
• Удалите бесполезные зависимости (будут упомянуты позже
• Выборочное удаление некоторых зависимостей
• сжатие кода
• babel-polyfill
• Scope Hoisting

Оптимизируйте время упаковки

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

Загрузчик svg-sprite-loader, который мы используем в проекте, автоматически выполняет svg-spirte для каждой иконки svg. Но мы знаем, что когда на эти значки ссылаются, мы редко их изменяем. Особенно что-то вроде значка флага, но нам нужно переупаковывать каждую сборку. Поэтому мы можем svg-спрайтить эти иконки заранее. Рекомендовать веб-сайту заранее спрайтить различные значки svg и автоматически ссылаться на них:

iconmoon

Ежедневная точка оптимизации времени упаковки

• внешние компоненты избегают упаковки больших сторонних зависимостей
• dll-plugin предварительно упакованные сторонние зависимости
• многопроцессорность happypack, кеширование

• Кэширование и инкрементные сборки

  • babel-loader?cacheDirectory
  • webpack cache:true
• Уменьшить поиск сборки или разрешить псевдоним пути компиляции
• Объем бетонной упаковки включает исключение

Суммировать

Анализируя json выходных зависимостей webpack, мы можем интуитивно получить следующие данные:

• Все зависимые файлы и их размеры
• На какие файлы ссылается каждый зависимый файл
• Сторонние зависимости, от которых зависит проект

С помощью этих данных мы можем легко оптимизировать существующие проекты.

Жизнь продолжается и продолжается. Давайте попрощаемся со всем этим неприятным кодом!