Tree shaking: Подробное руководство

Прежде чем начать нам нужно понять, какие типы модулей есть в экосистеме JavaScript. Приложения на JavaScript усложнились и возросло количество выполняемых ими задач. Стала очевидной необходимость разделения таких задач на изолированные области. Эти подзадачи мы называем модулями. Их основная цель — предотвратить повторение кода и переиспользовать код.

Что такое tree shaking?

Проще говоря, tree shaking означает удаление недостижимого кода (также известного как мертвый код) из пакета. В переводе tree shaking переводится как встряхивание дерева. Почему? Проведем аналогию. Можно представить свое приложение в виде дерева. Исходный код и библиотеки, которые вы фактически используете, представляют собой зеленые, живые листья дерева. Мертвый код представляет собой коричневые мертвые листья дерева, которые появляются осенью. Чтобы избавиться от опавших листьев, нужно встряхнуть дерево, чтобы они опали.

Этот термин был впервые популяризирован в сообществе фронтенд разработчиков команды Rollup. Но авторы всех динамических языков боролись с этой проблемой гораздо раньше. Идея алгоритма встряхивания дерева восходит как минимум к началу 1990-х годов. В области JavaScript tree shaking стал возможным со времен спецификации ECMAScript модулей (ESM) в ES2015, известной как ES6. С тех пор tree shaking была включена по умолчанию в большинстве сборщиков, потому что они уменьшают размер результирующего кода без изменения поведения программы. Основная причина этого заключается в том, что ESM являются статическими по своей природе. Давайте разберем, что это значит.

ES модули и CommonJS

CommonJS предшествует спецификации ESM. Он появился на несколько лет раньше. Он появился чтобы решить проблему отсутствия поддержки переиспользуемых модулей в экосистеме JavaScript. В CommonJS есть функция require(), которая извлекает внешний модуль на основе предоставленного пути и добавляет его в область видимости во время выполнения. Функция require является такой же функцией, как и любая другая функция. Это делает ее достаточно сложной для оценки результата вызова во время компиляции. Кроме того, возможно добавление вызовов require в любом месте кода — в вызове другой функции, в операторах if/else, в операторах switch и т. д.

В результате широкого внедрения CommonJS архитектуры, спецификация ESM остановилась на новой архитектуре, в которой модули импортируются и экспортируются с помощью соответствующих ключевых слов import и export. Поэтому больше никаких вызовов функций для добавления модулей. ESM также разрешает только объявления верхнего уровня, их вложение в какую-либо другую структуру невозможно. Это и делает его статичным. ESM не зависят от запуска во время выполнения.

Область применения и побочные эффекты

Есть еще одно препятствие, которое нужно преодолеть, чтобы избежать раздувания кода: побочные эффекты (сайд эффекты, side effects). Считается, что функция имеет побочные эффекты, когда она изменяет или зависит от факторов, внешних по отношению к области выполнения. Функция с побочными эффектами считается нечистой (impure function). Чистая функция (pure function) всегда будет давать один и тот же результат при каждом запуске, независимо от контекста или среды, в которой она была запущена.

const pure = (a: number, b: number): number => a + b
const impure = (c: number): number => window.foo.number + c

Сборщики стараются максимально оценить предоставленный код, чтобы определить, является ли модуль чистым. Но оценка кода во время компиляции или во время связывания может зайти слишком далеко. Поэтому предполагается, что пакеты с побочными эффектами не могут быть должным образом устранены, даже если они полностью недоступны. Из-за этого сборщики принимают ключ внутри файла package.json модуля, который позволяет разработчику заявить, не имеет ли модуль побочных эффектов. Таким образом, разработчик может отказаться от оценки кода и сказать сборщику, что код в конкретном пакете может быть исключен, если нет доступного импорта или оператора require, связывающего его. Это не только делает пакет более компактным, но также может ускорить время компиляции.

{
    "name": "some-package",
    "sideEffects": false
}

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

В дополнение к полю sideEffects также можно указать чистоту для каждого файла, добавляя встроенный комментарий /*@__PURE__*/ к вызову метода.

const x = */@__PURE__*/eliminated_if_not_called()

Эта встроенная аннотацию полезна для разработчика-потребителя. Она полезна в случае, если пакет не объявил sideEffects: false или в случае, если библиотека действительно представляет побочный эффект для определенного метода.

Оптимизация Webpack

Начиная с версии 4, Webpack требует все меньше конфигураций, используя при этом лучшие практики. Несколько плагинов было включено в ядро. Если вы не большой эксперт в webpack или если ваше приложение не содержит специфических сценариев, то tree shaking зависимостей — это вопрос всего одной строки. Файл webpack.config.js имеет корневое поле с именем mode. Всякий раз, когда значение этого свойства production, оно полностью оптимизирует ваши модули. Помимо устранения мертвого кода с помощью TerserPlugin, mode: production присвоит хэшированные имена для модулей и чанков, а также активирует следующие плагины:

• flag dependency usage
• flag included chunks
• module concatenation
• no emit on errors.

Не случайно все это происходит именно в production режиме. Вы не захотите, чтобы ваши зависимости были полностью оптимизированы в режиме разработки, потому что это значительно усложнит отладку. Поэтому я бы предложил использовать один из двух подходов. Для указания режима можно передать флаг режима в интерфейс командной строки Webpack:

# это значение перезапишет значение указанное в webpack.config.js
webpack --mode=production

Либо можно использовать переменную среды process.env.NODE_ENV в webpack.config.js:

mode: process.env.NODE_ENV === 'production' ? 'production' : development

В этом случае вы должны не забыть передать --NODE_ENV=production при развертывании приложения. Оба подхода являются абстракцией поверх известного плагина definePlugin из Webpack 3 и ниже. Какой вариант вы выберете, абсолютно не имеет значения.

Webpack 3 и ниже

Стоит отметить, что сценарии и примеры в разделе “Webpack 3 и ниже” могут не применяться к последним версиям Webpack и другим сборщикам. В этом разделе рассматривается использование UglifyJS 2 вместо Terser. UglifyJS — это пакет, из которого появился Terser, поэтому оценка кода между ними может различаться. Поскольку Webpack 3 и ниже не поддерживает свойство sideEffects в package.json, все пакеты должны быть полностью оценены, прежде чем код будет удален. Уже одно это делает подход менее эффективным, но также необходимо учитывать несколько предостережений.

Как упоминалось выше, компилятор не может сам определить, когда пакет входит в глобальную область. Но это не единственная ситуация, в которой он пропускает tree shaking. Есть более неочевидные сценарии. Рассмотрим пример пакета из документации Webpack:

// transform.js

import * as mylib from 'mylib';

export const someVar = mylib.transform({
  // ...
});

export const someOtherVar = mylib.transform({
  // ...
});

А это его использование:

// index.js

import { someVar } from './transforms.js';

// Use `someVar`...

Невозможно определить, вызывает ли mylib.transform побочные эффекты. Таким образом, никакой код не будет удален. Вот другие ситуации с аналогичным исходом:

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

Инструмент, который может помочь компилятору заставить tree shaking работать, называется babel-plugin-transform-imports. Он разделит все элементы и именованные экспорты на экспорты по умолчанию, что позволит оценивать модули по отдельности.

// до трансформации
import { Row, Grid as MyGrid } from 'react-bootstrap';
import { merge } from 'lodash';

// после трансформации
import Row from 'react-bootstrap/lib/Row';
import MyGrid from 'react-bootstrap/lib/Grid';
import merge from 'lodash/merge';

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

Поднятие (hoisting) и время компиляции

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

(function (modulesMap, entry) {
  // provided CommonJS runtime
})({
  "index.js": function (require, module, exports) {
     let { foo } = require('./foo.js')
     foo.doStuff()
  },
  "foo.js": function(require, module, exports) {
     module.exports.foo = {
       doStuff: () => { console.log('I am foo') }
     }
  }
}, "index.js")

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

// moduleA.js
let $moduleA$export$doStuff = () => ({
  doStuff: () => {}
})

// index.js
$moduleA$export$doStuff()

Этот подход полностью совместим с ESM; кроме того, это позволяет оценке кода легко обнаруживать модули, которые не вызываются, и удалять их. Недостаток этого подхода заключается в том, что во время компиляции требуется значительно больше времени, потому что он касается каждого оператора и сохраняет пакет в памяти во время процесса. Это важная причина, по которой производительность пакетов стала еще более серьезной проблемой и почему скомпилированные языки используются в инструментах для веб-разработки. Например, esbuild — это сборщик, написанный на Go, а SWC — это компилятор TypeScript, написанный на Rust, который интегрируется со Spark, сборщиком, также написанным на Rust.

Избегайте преждевременной транспиляции

Есть одна проблема, которая, к сожалению, довольно распространена и может иметь негативные последствия для tree shaking. Короче говоря, это происходит, когда вы работаете со специальными загрузчиками, интегрируя разные компиляторы в свой сборщик. Распространенными комбинациями являются TypeScript, Babel и Webpack — во всех возможных сочетаниях. И у Babel, и у TypeScript есть собственные компиляторы, и соответствующие загрузчики позволяют разработчику использовать их для упрощения интеграции. И в этом кроется скрытая угроза.

Эти компиляторы достигают вашего кода до оптимизации кода. И по умолчанию или из-за неправильной настройки эти компиляторы часто выводят модули CommonJS вместо ESM. Как упоминалось в предыдущем разделе, модули CommonJS являются динамическими и, следовательно, не могут быть должным образом оценены для устранения мертвого кода. Этот сценарий становится все более распространенным в настоящее время с ростом «изоморфных» приложений (т. е. приложений, которые выполняют один и тот же код как на стороне сервера, так и на стороне клиента). Поэтому обязательно проверяйте код, который получает алгоритм оптимизации.

Tree shaking чеклист

Теперь, когда вы знаете все тонкости того как создаются бандлы и работает tree shaking, давайте выведем чеклист. Надеюсь, это сэкономит вам время и позволит оптимизировать не только производительность вашего кода, но, возможно, даже время сборки.

• Используйте ESM, и не только в своей собственной кодовой базе, но также отдавайте предпочтение пакетам, которые сами выдают ESM.
• Убедитесь, что вы точно знаете, какие из ваших зависимостей (если таковые имеются) не объявили sideEffects или не установили их в true.
• Используйте встроенную аннотацию для объявления вызовов методов, которые являются чистыми при использовании пакетов с побочными эффектами.
• Если вы выводите модули CommonJS, обязательно оптимизируйте свой пакет, прежде чем преобразовывать операторы импорта и экспорта.

Создание пакетов

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

• Включите экспорт ESM.
• Добавьте "type": "module"
• Укажите точку входа "module": "./path/entry.js"

И вот пример, который получается, когда соблюдаются все лучшие практики и вы хотите поддерживать как веб-среду, так и среду Node.js:

{
    // ...
    "main": "./index-cjs.js",
    "module": "./index-esm.js",
    "exports": {
        "require": "./index-cjs.js",
        "import": "./index-esm.js"
    }
    // ...
}

В дополнение к этому команда Skypack ввела показатель качества пакета в качестве эталона, чтобы определить, настроен ли данный пакет на долговечность и использует ли лучшие практики. @skypack/package-check может быть добавлен как devDependency в ваш пакет, чтобы легко выполнять проверки перед каждым релизом. Также рекомендую прочитать статью Создание tree-shaking библиотеки с Rollup и Vue, в ней также рассказано почему Webpack не подходит для создания tree-shaked библиотек.

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

Что такое побочные эффекты?

Побочным эффектом (сайд эффект, side effect) в контексте модуля ECMAScript является код, который выполняет некоторое внешне видимое поведение (то есть поведение, видимое вне модуля) при загрузке модуля. Вот пример:

import { registerThing } from 'thing-registry';
const store = registerThing( THING_KEY, { /* ... */ } );

registerStore вызывается на верхнем уровне, что означает, что он будет запущен, как только модуль будет впервые импортирован. Эти изменения видны внешне, так как вещи модифицируются во внешнем хранилище, которое находится в другом модуле (thing-registry). Другие примеры побочных эффектов включают установку глобальных значений в window или добавление поведения браузера с помощью полифиллов (polyfills).

Однако, если бы это произошло внутри функции init, которая не вызывается при загрузке модуля, то это больше не было бы побочным эффектом:

import { registerThing } from 'thing-registry';
 
export function init() {
  const store = registerThing( THING_KEY, { /* ... */ } );
}
 
// `init` не вызывается на верхнем уровне модуля,
// и таким образом импорт этого модуля не вызывает сайд эффектов.

Объявление переменной или выполнение каких-либо изменений на верхнем уровне, которые влияют только на текущий модуль, также не является побочным эффектом, поскольку они содержатся в модуле:

import list from './list';
 
// не сайд эффект
let localVariable = [];
 
// тоже не сайд эффект
for ( const entry of list ) {
  localVariable.push( processListEntry( entry ) );
}

Влияние побочных эффектов на сборку

Большинство современных сборщиков реализуют tree shaking, при котором неиспользуемый код удаляется из финальных бандлов, так как в этом нет необходимости. Это становится важным в библиотеках, которые предлагают множество различных функций, поскольку потребители этой библиотеки могут использовать только небольшую ее часть и не хотят, чтобы их бандлы были больше, чем необходимо. Таким образом, пакеты и библиотеки должны предпринять шаги для обеспечения того, чтобы их действительно можно было правильно встряхнуть. Это возвращает нас к побочным эффектам. Как мы видели, побочные эффекты — это код, который запускается просто в силу импорта модуля и оказывает какое-то внешнее влияние. Это означает, что код не может быть вытряхнут деревом; Он должен работать, потому что он изменяет вещи за пределами модуля, которые могут понадобиться в другом месте. К сожалению, побочные эффекты трудно определить автоматически, и некоторые сборщики (например, webpack) ошибаются в сторону осторожности, предполагая, что каждый модуль потенциально имеет побочные эффекты. Это становится проблемой для index модулей, которые повторно экспортируют (ре-экспортируют) вещи из других модулей, поскольку это фактически означает, что все, что там есть, теперь должно быть объединено вместе:

// index.js
 
export { a, b } from './module1';
export { c, d, e } from './module2';
export { f } from './module3';
 
// Tree shaking не может быть применен, т.к. сборщик не знает
// имеют ли эти ре-экспортируемые модули сайд эффекты.

Рассказываем сборщикам о побочных эффектах

Поскольку сборщики не могут сами разобраться в побочных эффектах, нам нужно явно заявить о них. Это делается в package.json пакетов. Это означает, что объявление побочных эффектов является обязанностью пакета, и для пакетов, которые этого не делают, webpack, скорее всего, не сможет ничего стереть. Пользователи такого пакета могут в конечном итоге вытащить все это в свою сборку, даже если они используют только небольшую часть пакета, часто без простого способа обойти его. Так как же заявить о побочных эффектах? Лучший способ сделать это зависит от того, насколько вы их используете и где они находятся в вашем коде. Очень часто ваш пакет вообще не будет использовать никаких побочных эффектов. В этой ситуации вы можете просто установить sideEffects значение false:

{
  "name": "package",
  "sideEffects": false
}

Если в нем есть несколько файлов с побочными эффектами, вы можете перечислить их:

{
  "name": "package",
  "sideEffects": [ "dist/store.js", "dist/polyfill.js" ]
}

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

Webpack поддерживает ряд сложных функций сопоставления, поэтому другой подход, который вы можете использовать, заключается в инвертировании вещей и объявлении путей без побочных эффектов, оставляя webpack предполагать, что все остальное может иметь побочные эффекты:

{
  "name": "package",
  "sideEffects": [
    "!(dist/(components|utils)/**)"
  ]
}

Приведенный выше пример говорит сборщику, что он должен предполагать, что все, что находится за пределами каталогов components и utils, содержит побочные эффекты. Этот подход должен гарантировать, что все в components и utils может быть встряхнуто деревом без проблем с побочными эффектами и потенциально вызовет проблемы только в том случае, если один из файлов там использует побочные эффекты. В некоторых ситуациях может быть предпочтительнее пометить конкретный вызов функции как не имеющий побочных эффектов, а не весь файл. Рассмотрим следующий пример:

function noSideEffects() {
  // Do something.
}
 
noSideEffects();

Сборщик не может определить, содержит ли вызов верхнего уровня noSideEffects какие-либо побочные эффекты. Одним из решений было бы включение модуля в поле package.json sideEffects, как мы видели выше. Однако мы также можем обрабатывать его в коде с помощью подсказки PURE:

function noSideEffects() {
  // Do something.
}
 
/*#__PURE__*/ noSideEffects();

Потеря побочных эффектов у потребителя

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

// index.js
 
import 'side-effectful-module';
 
export { a, b } from './impl';

// impl.js
 
function a() {
  // что-то делает
}
 
function b() {
  // делает что-то, что зависит от произошедших сайд эффектов
}

В index.js мы видим то, что часто называют “голым импортом” (naked import). Этот синтаксис означает, что мы не используем ни один из экспортов модуля, и нас фактически интересуют только его побочные эффекты. Голый импорт сам по себе не является побочным эффектом, но он является очень сильным сигналом о том, что побочные эффекты присутствуют во всем, что вы импортируете. index.js не делает ничего, кроме импорта side-effectful-module, просто ре-экспортируя функции из impl.js. Ключевым моментом здесь является то, что функции в impl.js на самом деле зависят от побочного эффекта, который происходит в index.js. Если встряхивание деревьев отключено, например, в режиме разработки, все будет работать правильно. Однако, если встряхивание дерева включено, модуль index.js может быть удален из дерева, оставив только фактические функции из impl.js. Если это произойдет, побочный эффект будет потерян, и b потерпит неудачу. То же самое может произойти, если импорт выполняется в дочернем модуле:

// index.js
 
import { unused } from './util';
 
function b() {
  // делает что-то, что зависит от произошедших сайд эффектов
}
 
// Этот модуль не использует функцию `unused`.

// util.js
 
import "side-effectful-module";
 
export function unused() {
  // делает что-то, что зависит от произошедших сайд эффектов
}

Поскольку unused не используется в index.js, он будет вытряхнут деревом. Это означает, что ничего из impl.js больше не нужно, поэтому ничего из этого не будет загружено. В очередной раз мы теряем побочный эффект, хотя он необходим.

Предотвращение побочных эффектов при встряхивании деревьев

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

// index.js
 
import "side-effectful-module";
import { unused } from './util';
 
function b() {
  // делает что-то, что зависит от произошедших сайд эффектов
}
 
// этот модуль все еще не использует `unused`.

Это гарантирует, что side-effectful-module будет выполняться перед любым кодом в index.js и не будет вытряхиваться из дерева. Обратите внимание, что теперь мы импортируем побочный эффект в оба модуля, но это нормально! Модули ES запускаются только один раз, а это означает, что их побочные эффекты также будут запускаться только один раз, независимо от того, сколько файлов они импортированы.

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

В итоге получилась тонна информации, поэтому давайте попробуем обобщить практические советы:

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