Что такое сайд эффекты в ES модулях и как они влияют на бандл?

Многие проекты используют 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.
• Если ваша библиотека содержит побочные эффекты, вы все равно можете включить встряхивания деревьев насколько это возможно. Перечислите файлы с побочными эффектами в явном виде или используйте обратные условия, чтобы перечислить пути, которые не имеют побочных эффектов.
• Если вы полагаетесь на побочные эффекты от внешнего модуля, обязательно импортируйте этот модуль везде, где вы их используете.

Если у вас нет опыта server side программирования, переменные среды могут показаться чем-то магическим. Этот недостаток знаний может поставить вас в тупик, когда вы закончите создавать приложения todo на localhost и попытаетесь создать продакшн сборку в первый раз. Если вы хотите узнать, как использовать переменные среды в ваших собственных инструментах, или глубоко погрузиться в то, как переменные среды работают в React, вы можете продолжить чтение этой статьи. Но если вы ищете быстрое решение и используете Create React App, ознакомьтесь с документацией здесь. Пользователи NextJS, ознакомьтесь с документацией здесь.

Проблема, которую мы решаем

Как объявить различные URL-адресов API для локальной разработки и для продакшн сборки.

Как решить эту проблему

Использовать переменные среды. При работе с React переменные среды — это переменные, доступные через глобальный объект process.env. Этот глобальный объект предоставляется вашей средой через NodeJS. И поскольку у нас нет NodeJS в браузере, нам понадобится webpack. В этой статье рассмотрим два способа установки и использования переменных среды для ваших React проектов с помощью webpack: с помощью скриптов npm и с помощью файла .env.

Способ 1: Использование скриптов npm для установки переменных среды

Во-первых, установите webpack и webpack-cli из npm:

npm install --save-dev webpack webpack-cli

Перейдите в файл package.json, проверьте поле scripts и найдите команды, которые запускают webpack. Вероятно, это будет выглядеть примерно так:

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

Давайте добавим некоторые переменные окружения с флагом --env в scripts:

{
  // ...
  scripts: {
    "dev": "webpack --env.API_URL=http://localhost:8000 --config webpack.config.dev.js",
    "build": "webpack --env.API_URL=https://www.myapi.com --config webpack.config.build.js"
  }
}

Мы добавили --env.API_URL= часть в обоих скриптах. Теперь запустите команду npm run dev, перейдите к React компоненту и используйте process.env.API_URL:

const App = () => <h1>{process.env.API_URL}</h1>;

И тут проект должен сломаться.

Сломается он потому, что когда мы используем переменные окружения в клиентском коде, они на самом деле просто служат заполнителями, которые будут заменены при компиляции нашего кода. Проблема в том, что мы не сказали webpack скомпилировать эти переменные в реальные значения. Давайте сделаем это в нашем конфигурационном файле webpack с плагином DefinePlugin:

const webpack = require('webpack'); // DefinePlugin это часть webpack, поэтому это require обязателен

// возвращаем функцию из config файла
// переменная `env` будет просто объектом { API_URL: 'http://localhost:8000' }
// в ней будут содержаться все переменные среды, которые мы указали в package.json

module.exports = (env) => {
  // этот объект это сама конфигурация webpack
  return {
    plugins: [
      // добавим плагин в список плагинов
      new webpack.DefinePlugin({ `process.env.API_URL`: JSON.stringify(${env.API_URL}) })
    ]
  };
};

DefinePlugin требует, чтобы вы буквально определили свои «переменные среды». Вы также можете применить .reduce к переменным среды, чтобы получить объект:

module.exports = (env) => {
  // создаем объект из переменных среды
  const envKeys = Object.keys(env).reduce((prev, next) => {
    prev[`process.env.${next}`] = JSON.stringify(env[next]);
    return prev;
  }, {});

  return {
    plugins: [
      new webpack.DefinePlugin(envKeys)
    ]
  };
};

Если вы запустите команду сейчас, все скомпилируется, и ваш process.env.API_URL будет скомпилирован в правильный URL-адрес на основе переменной среды.

Способ 2: Использование файла .env для установки переменных среды

Вся идея здесь состоит в том, чтобы создать файл (называемый просто .env), заполненный переменными среды. Чтобы защитить пароли и другие значения переменных среды, добавьте файл .env в .gitignore. Фронтенд код будет ссылаться на одну и ту же переменную среды (process.env.API_URL) в обеих средах (при локальной разработке и на продакшене), но поскольку вы определили разные значения в своих .env, скомпилированные значения будут отличаться.

Создадим файл .env

Этот файл должен находиться в корневом каталоге проекта и называться .env. Добавим переменную:

API_URL=http://localhost:8000

Обработка файла .env

Теперь нам нужен какой-то способ обработки файлов и их содержимого. Для этого мы собираемся использовать популярный npm пакет под названием dotenv. Dotenv широко используется (create-react-app использует его). Он будет получать переменные из нашего файла .env и добавлять их в глобальный process.env.

$ npm install --save-dev dotenv

Добавление переменных в проект React

Есть одна проблема. Dotenv работает только на стороне сервера. А мы хотим использовать переменные среды на стороне клиента, на фронтенде. В данном случае мы разрабатываем клиентскую часть. И dotenv нужна какая-то среда для фактического хранения переменных. Здесь поможет Webpack. Воспользуемся плагином DefinePlugin в нашей webpack конфигурации:

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

module.exports = () => {
  // dotenv вернет объект с полем parsed 
  const env = dotenv.config().parsed;
  
  // сделаем reduce, чтобы сделать объект
  const envKeys = Object.keys(env).reduce((prev, next) => {
    prev[`process.env.${next}`] = JSON.stringify(env[next]);
    return prev;
  }, {});

  return {
    plugins: [
      new webpack.DefinePlugin(envKeys)
    ]
  };
};

При необходимости проверьте параметры конфигурации dotenv в документации на github. Вызов .config() в dotenv вернет объект со всеми переменными среды, установленными в вашем файле .env через поле parsed. Теперь давайте проверим наш React код:

const App = () => <h1>{process.env.API_URL}</h1>;

И это работает! Он показывает значение переменной среды API_URL, определенной в .env. Осталась только одна проблема: нам все еще нужно определить различные API_URL для локальной разработки и продакшена.

Различные переменные среды для разных сред

Вся идея состоит в том, чтобы создать разные файлы .env для разных сред и позволить webpack выбрать правильный файл .env в зависимости от активной среды. Поэтому создайте два файла в корневом каталоге проекта:

• .env (содержит все переменные среды для продакшн)
• .env.development (содержит все переменные среды для локальной разработки)

Чтобы было ясно: мы добавляем к имени файла .env сопоставление имени среды. Общепринятой практикой является использование исходного файла .env для продакшн сборки, поэтому мы не будем добавлять постфикс для продакшн .env .

Настройка активной среды с помощью scripts в package.json

Мы собираемся использовать scripts (как мы это делали в методе 1), чтобы установить текущую среду в нашем package.json:

{
  "scripts": {
    "dev": "webpack --env.ENVIRONMENT=development --config webpack.config.dev.js",
    "build": "webpack --env.ENVIRONMENT=production --config webpack.config.build.js"
  }
}

Так как мы определили нашу среду в нашем package.json, теперь она доступна в нашей конфигурации webpack. Следующим шагом будет переход к webpack конфигурации и дать ему использовать файл .env, принадлежащий активной среде. Как и раньше, мы используем dotenv, но теперь мы указываем пользовательский path в параметрах.

const webpack = require('webpack');
const dotenv = require('dotenv');
const fs = require('fs'); // для проверки существования файла
const path = require('path'); // для получения текущего пути

module.exports = (env) => {
  // получаем корневой путь (предполагаем, что webpack config лежит в корне проекта)
  const currentPath = path.join(__dirname);
  
  // путь по умолчанию (будет использован для продакшена - `.env`)
  const basePath = currentPath + '/.env';

  // склеиваем имя среды с именем файла для получения имени env файла
  const envPath = basePath + '.' + env.ENVIRONMENT;

  // проверяем существует ли env файл, если нет используем имя по умолчанию
  const finalPath = fs.existsSync(envPath) ? envPath : basePath;

  // устанавливаем параметр path в dotenv
  const fileEnv = dotenv.config({ path: finalPath }).parsed;
  
  // сделаем reduce, чтобы получить объект
  const envKeys = Object.keys(fileEnv).reduce((prev, next) => {
    prev[`process.env.${next}`] = JSON.stringify(fileEnv[next]);
    return prev;
  }, {});

  return {
    plugins: [
      new webpack.DefinePlugin(envKeys)
    ]
  };

Эта вся необходимая настройка, но вы можете создать больше .env файлов для большего количества сред (например, .env.staging) по аналогии.