Tree Shaking: какво е, механизъм за премахване на мъртъв код и инструменти

Какво е Tree Shaking?

Tree Shaking (разклащане на дърво) — техника за оптимизация на код, при която модули и функции, неизползвани в приложението, се изключват от крайния пакет. Терминът е въведен от екипа на Rollup през 2015 година и метафорично описва процеса: дървото на зависимостите се разклаща и неизползваните клони падат. За разлика от ръчната оптимизация, Tree Shaking се изпълнява автоматично на етапа на изграждане.

Tree Shaking работи само с ES-модули (ECMAScript Modules), където зависимостите се определят статично чрез import и export. CommonJS (require/module.exports) не поддържа Tree Shaking, защото require се изпълнява динамично — инструментът за изграждане не може предварително да определи кои функции реално се използват. Съвременните библиотеки (Lodash, Moment.js, RxJS) пускат ES версии за поддръжка на Tree Shaking.

Rollup: пионер на Tree Shaking

Rollup — първият инструмент за изграждане, внедрил Tree Shaking през 2015 г. За разлика от Webpack, Rollup от самото начало е проектиран за ES-модули и извършва по-агресивно премахване на мъртъв код. Rollup анализира не само отделни експорти, но и цели модули: ако модулът няма странични ефекти и нито един експорт не се използва, Rollup изключва целия модул от пакета.

Rollup е особено ефективен за библиотеки и SDK, където всеки килобайт има значение. Framework-ът Vue.js използва Rollup за изграждане на production версията. React премина към Rollup през 2020 г. За приложения по-често се използва Webpack поради по-богатата екосистема от плъгини (Hot Module Replacement, code splitting, CSS modules), но за максимален Tree Shaking при изграждане на библиотеки, Rollup остава индустриален стандарт.

Икономията от Tree Shaking силно зависи от архитектурата на проекта. В React приложение с библиотека Ant Design, Tree Shaking може да премахне до 70% от кода на UI компонентите. В проект, където всички импорти са специфични и точни, икономията ще бъде 5–15%. Средната икономия според изследвания на Webpack е 30–40% от размера на пакета.

Какво е мъртъв код

Как работи Tree Shaking: статичен анализ на модули

Механизмът на Tree Shaking се основава на графа на зависимостите (dependency graph), който инструментът за изграждане изгражда от всички import/export в проекта. На първия етап инструментът за изграждане обхожда всички файлове от входната точка (entry point) и събира дървото от модули. На втория етап се анализира кои експорти от всеки модул реално се импортират в други модули.

За всеки модул Webpack или Rollup маркира експортите като използвани или неизползвани. Неизползваните експорти се изключват от пакета. Самият модул обаче остава в пакета, ако поне един негов експорт се използва. Пълното изключване на модул е възможно само чрез флага sideEffects или ако модулът не съдържа никакви странични ефекти.

Пример: преди и след Tree Shaking

// utils.js — модул с функции
export function formatDate(date) {
  return date.toISOString().slice(0, 10);
}

export function formatCurrency(amount) {
  return "$" + amount.toFixed(2);
}

export function slugify(text) {
  return text.toLowerCase().replace(/\s+/g, "-");
}

// app.js — входна точка
import { formatDate } from "./utils";

const today = formatDate(new Date());
console.log(today);

// След Tree Shaking — в пакета само formatDate
function formatDate(date) {
  return date.toISOString().slice(0, 10);
}
const today = formatDate(new Date());
console.log(today);

Tree Shaking изключи formatCurrency и slugify от крайния пакет, тъй като не се импортират в app.js. Размерът на модула utils.js намаля от 3 функции на 1. Ако utils.js съдържа side effects (напр. глобална инициализация), Tree Shaking няма да може да премахне дори неизползваните експорти.

Tree Shaking в Webpack: конфигурация и оптимизация

Webpack включва вградена поддръжка за Tree Shaking чрез плъгина TerserPlugin в production режим. За включване на Tree Shaking са достатъчни две условия: mode е зададен на production (mode: "production") и модулите използват ES синтаксис (import/export). Webpack автоматично маркира неизползваните експорти и ги предава на Terser за премахване.

Допълнителна конфигурация usedExports: true в optimization.webpack.config.js включва детайлен анализ на използването на експорти вътре в модула. Тази опция определя кои експорти реално се използват (used) и кои са само експортирани (provided). Комбинацията от usedExports и Terser дава максимална ефективност при премахване на мъртъв код.

Конфигурация на Webpack за Tree Shaking

// webpack.config.js — конфигурация на Tree Shaking
module.exports = {
  mode: "production",
  entry: "./src/app.js",
  output: {
    filename: "bundle.js",
  },
  optimization: {
    usedExports: true,
    minimize: true,
    concatenateModules: true,
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules\/(?!(my-lib)\/).*/,
        use: {
          loader: "babel-loader",
          options: {
            presets: [
              ["@babel/preset-env", { modules: false }],
            ],
          },
        },
      },
    ],
  },
};

Ключовият параметър — modules: false в @babel/preset-env. Babel по подразбиране преобразува ES-модули в CommonJS, което убива Tree Shaking. modules: false забранява на Babel да преобразува import/export, запазвайки ES синтаксиса за Webpack. concatenateModules допълнително обединява модули в общ обхват на видимост, намалявайки броя на IIFE и размера на пакета.

Проблемът със side effects и флагът sideEffects

Side effects (странични ефекти) — действия на модула при неговото импортиране, които не са свързани с експортираните стойности: глобални стилове (import "./styles.css"), полифили (import "core-js/stable"), инициализация на глобални променливи или регистрация на Service Worker. Ако модулът съдържа side effects, инструментът за изграждане не може безопасно да го премахне от пакета, дори ако нито един експорт не се използва.

Флагът sideEffects в package.json информира инструмента за изграждане кои модули в пакета нямат странични ефекти. За пакет, където всички модули са чисти (само експорт на функции), трябва да се зададе "sideEffects": false. За пакети с CSS или полифили — масив от пътища към файлове със странични ефекти: "sideEffects": ["*.css"]. Без този флаг Tree Shaking няма да премахне дори неизползваните функции.

Как да определите side effects в собствения си код

За да проверите дали модулът има странични ефекти, задайте въпроса: ще изпълни ли този import някакви действия, несвързани с експорта на стойности? import "./styles.css" добавя CSS в DOM — това е side effect. import { throttle } from "lodash-es" няма side effects — само прави функцията throttle достъпна. Полифилите (import "core-js/stable") имат side effects — променят глобалните прототипи.

За собствени модули се препоръчва: изнасяне на стилове и полифили в отделни входни точки, разделяне на чисти помощни програми (функции без side effects) от модули със странични ефекти (инициализация, логване, регистрация на Service Worker). В package.json на проекта от най-високо ниво задавайте "sideEffects": false само ако всички модули са чисти. Ако има стилове — задавайте "sideEffects": ["*.css"] точно.

Пример за конфигурация на sideEffects

{
  "name": "my-ui-lib",
  "version": "2.1.0",
  "sideEffects": [
    "*.css",
    "polyfills.js"
  ],
  "module": "dist/index.esm.js",
  "main": "dist/index.cjs.js"
}

"sideEffects": ["*.css", "polyfills.js"] означава: всички CSS файлове имат странични ефекти (не могат да бъдат премахнати) и polyfills.js също. Всички останали JS файлове в пакета са чисти — могат безопасно да бъдат shake-нати. Полето module указва пътя към ES версията на пакета, която инструментът за изграждане трябва да използва вместо CommonJS версията (main) за Tree Shaking.

Tree Shaking в React Native и Metro

React Native с Metro Bundler поддържа ограничена версия на Tree Shaking. Metro не извършва пълен статичен анализ на използваните експорти (usedExports) като Webpack. Вместо това Metro разчита на Terser за премахване на неизползваната част от модулите на етапа на минификация. Ефективността на този подход е по-ниска от пълния Tree Shaking в Webpack.

За максимална оптимизация на React Native проекти се препоръчва: използване на библиотеки с ES-модули (поле module в package.json), свързване на плъгини babel-plugin-transform-remove-console за премахване на дебъг код и конфигуриране на Metro transformer.minifierConfig за Terser. Допълнително Ram Bundle (разделяне на пакета на модули) намалява зареждането на неизползвани екрани.