Как импортировать Lodash для наименьших размеров сборки - PullRequest
Новая
       9

Как импортировать Lodash для наименьших размеров сборки

2 голосов
/ 16 октября 2019

Я забочусь о размерах сборки приложения javascript. Я делаю то, что могу (в пределах разумного), чтобы размеры сборки были как можно меньше.

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

import * as _ from 'lodash';

Я слышал, что "гранулированный" импорт(как показано ниже) может улучшить размер сборки, но я не вижу ожидаемых результатов: 

import {get, map, set} from 'lodash';

Каков наилучший способ импорта lodash для достижения небольшого общего размера сборки?

1 Ответ

2 голосов
/ 16 октября 2019

Размеры сборки ОЧЕНЬ важны для вовлечения и сохранения пользователей - отличный вопрос. У меня была похожая проблема, и в наши дни я хочу создать как можно меньше сборок.

Я построил быстрый тест с использованием source-map-explorer - простого инструмента для анализа послевы запускаете сборку для вашего проекта (например, Angular, React). Хотя этот инструмент может быть очень полезен для анализа того, что находится в ваших пакетах, имейте в виду, что он минимизирован (как ваш процесс сборки), но не gzipped. Таким образом, это не то, с чем столкнулись бы ваши пользователи, предполагая, что вы используете хороший хост, использующий mod_deflate или сервер с аналогичным сжатием gzip / Brotli / etc.

Вот что я сделал для тестирования с использованием популярной библиотеки: React. Я следовал инструкциям, используя create-реакции-приложение, затем создал несколько вариантов и собрал их, используя yarn run build.

  • Тест 0: создание-реакции-приложение (не для машинописи)
  • Тест1: добавлен lodash через import * as _ from 'lodash'
  • Тест 2: удален lodash, добавлены lodash-ы и проделан import { upperCase } from 'lodash-es'
  • Тест 3: удален lodash-es, добавлен обратно в lodash и проделан import { upperCase } from 'lodash'

После процесса сборки я выполнил командную строку gzip, чтобы получить приблизительный размер gzip для «веб-пользователя». gzip *.js из выходного каталога сборки.

Мои результаты? Ну, время выполнения основной не меняется вообще. Основное немного различается в зависимости от текста, например, вызов включенной функции для гарантии того, что upperCase фактически «внедряется» в сборку, а не просто отбрасывается. Я не беспокоюсь об этих размерах, поэтому проигнорирую это.

Таким образом, я подведу итоги, используя размер chunk.js.gz (полные результаты приведены ниже):

  • Тест 0:41177 байт (базовый уровень)
  • Тест 1: 65540 байтов (+24363 байта для использования одной функции, ой!)
  • Тест 2: 43203 байта (+2026 байтов для использования одной функции - намного лучше !)
  • Тест 3: 65540 байт (снова +24363 байт, все еще болит)

Заключение? Используйте lodash-es для гранулированного импорта. Кроме того, для ясности кода и без переопределения имен других функций, таких как map, я остановился на этой стратегии:

import { map as _map, get as _get } from 'lodash-es'. 

Directory and file sizes thanks to `tree --du`

├── [ 42787] cra-default-test-0
│ ├── [ 41177] 2.284b2af8.chunk.js.gz
│ ├── [ 642] main.a1384886.chunk.js.gz
│ └── [ 808] runtime-main.3ba3833f.js.gz
├── [ 67174] cra-all-lodash-test-1
│ ├── [ 65540] 2.ef604131.chunk.js.gz
│ ├── [ 666] main.c259429e.chunk.js.gz
│ └── [ 808] runtime-main.3ba3833f.js.gz
├── [ 44845] cra-lodash-es-uppercase-only-test-2
│ ├── [ 43203] 2.2852311b.chunk.js.gz
│ ├── [ 674] main.131e67d8.chunk.js.gz
│ └── [ 808] runtime-main.3ba3833f.js.gz
├── [ 67188] cra-lodash-uppercase-only-test-3
│ ├── [ 65540] 2.0ccbb0bd.chunk.js.gz
│ ├── [ 680] main.c3d7426c.chunk.js.gz
│ └── [ 808] runtime-main.3ba3833f.js.gz
...