Как настроить Webpack, TypeScript и ts-loader

Используемый во многих современных проектах, Webpack, является инструментом, который оптимизирует ресурсы приложения, чтобы они работали более эффективно на любом устройстве. Webpack помогает компилировать и объединять модули в единый файл, уменьшая количество HTTP-запросов и, как следствие, повышая производительность приложения. С помощью Webpack код TypeScript компилируется в файл JavaScript, который удобен для браузера. С помощью загрузчиков (loaders) Webpack вы также можете конвертировать файлы Sass и Less в один CSS файл. В этой статье мы узнаем, как использовать Webpack для компиляции TypeScript в JavaScript, объединять исходный код в один JavaScript файл и использовать source map исходного кода для отладки. Мы также рассмотрим, как использовать плагины Webpack. Чтобы следовать инструкциям в этом руководстве, вам потребуется следующее:

• npm
• Node.js (≥v8.x)
• Редактор кода на ваш выбор (например, Visual Studio Code)
• Базовые знания TypeScript

Содержание

• Загрузчики Webpack
• Настройка Webpack и TypeScript
• Конфигурация Webpack
• Конфигурация TypeScript
• Конфигурация пакета
• Создание HTML-страниц с помощью HtmlWebpackPlugin
• Объединение CSS с MiniCssExtractPlugin
• Минимизация CSS
• Минификация JavaScript
• Использование CopyWebpackPlugin
• Отладка с помощью source map

Загрузчики Webpack

По умолчанию Webpack понимает только файлы JavaScript, рассматривая каждый импортированный файл как модуль. Webpack не может компилировать или объединять файлы, отличные от JavaScript, поэтому он использует загрузчики. Загрузчики сообщают Webpack, как компилировать и объединять статические ресурсы. Они используются для компиляции модулей TypeScript в JavaScript, обработки стилей приложений и даже линтинга кода с помощью ESLint. Некоторые загрузчики Webpack включают ts-loader, css-loader, style-loader и другие. Мы обсудим их позже в этом руководстве.

Настройка Webpack и TypeScript

Начнем с настройки нашего проекта. Во-первых, на вашем компьютере должен быть установлен TypeScript. Чтобы установить TypeScript глобально, используйте следующую команду:

npm install -g typescript

Глобальная установка TypeScript избавляет от необходимости устанавливать TypeScript каждый раз, когда вы начинаете новый проект. Далее мы установим пакеты webpack и ts-loader в качестве зависимостей в нашем проекте:

npm init -y
npm install -D webpack webpack-cli ts-loader webpack-dev-server

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

По умолчанию Webpack не нуждается в конфигурационном файле. Предполагается, что точкой входа для вашего проекта является src/index.js и выведет минимизированный и оптимизированный результат в dist/main.js. Если вы хотите использовать плагины или загрузчики, то вам нужно будет использовать конфигурационный файл Webpack, позволяющий указать, как Webpack будет работать с вашим проектом, какие файлы компилировать и где будет находиться выходной файл. Давайте добавим конфигурационный файл Webpack в наш проект. В корневой папке проекта создайте webpack.config.js со следующими конфигурациями:

const path = require('path');

module.exports = {
  entry: './src/index.ts',
  module: {
    rules: [
      {
        test: /\.ts?$/,
        use: 'ts-loader',
        exclude: /node_modules/,
      },
    ],
  },
  resolve: {
    extensions: ['.tsx', '.ts', '.js'],
  },
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist'),
  },
  devServer: {
    static: path.join(__dirname, "dist"),
    compress: true,
    port: 4000,
  },
};

Давайте рассмотрим некоторые параметры конфигурации Webpack. Во-первых, опция entry является отправной точкой для приложения, где Webpack начинает строить граф зависимостей. Webpack перейдет к другим модулям в зависимости от входного файла. Опция output указывает Webpack, куда сохранять бандлы (результаты сборки), и позволяет присвоить файлу имя. Наконец, опция module указывает Webpack, как обрабатывать модули с определенными правилами с помощью загрузчиков.

Конфигурация TypeScript

Конфигурационный файл TypeScript определяет, как TypeScript будет компилироваться в JavaScript, и определяет различные параметры компилятора, необходимые для транспиляции TypeScript. В корневой папке проекта создайте tsconfig.json и добавьте следующие конфигурации:

{
    "compilerOptions": {
        "noImplicitAny": true,
        "target": "ES5",
        "module": "ES2015"
    }
}

target — это версия JavaScript, в которую вы хотите транспилировать TypeScript, а module — это формат используемого оператора импорта. Вы можете установить модуль на CommonJS, ES6 или UMD, так как Webpack будет работать со всеми системами модулей.

Конфигурация проекта

Теперь нам нужно добавить сценарий Webpack, который будет запускать webpack.config.js файл для нас. Чтобы добавить сценарий Webpack, откройте package.json и добавьте следующие скрипты в опцию script:

• "dev": "webpack-dev-server --mode development",
• "build" : "webpack --mode production"

Файл package.json теперь будет содержать следующие параметры конфигурации:

{
  "name": "webpack-setup",
  "version": "1.0.0",
  "description": "",
  "main": "src/index.ts",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "dev": "webpack-dev-server --mode development",
    "build": "webpack --mode production"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "css-loader": "^6.7.1",
    "html-webpack-plugin": "^5.5.0",
    "mini-css-extract-plugin": "^2.6.1",
    "ts-loader": "^9.4.1",
    "webpack": "^5.74.0",
    "webpack-cli": "^4.10.0",
    "webpack-dev-server": "^4.11.1"
  }
}

Теперь давайте создадим простую программу TypeScript, которая будет вычитать два числа. Внутри папки src создайте index.ts и добавьте следующий код TypeScript:

import { subtract } from "./app";

function init() {
    const form = document.querySelector("form");
    form?.addEventListener("submit", submitHandler);
}

function submitHandler(e: Event) {
    e.preventDefault();
    const num1 = document.querySelector("input[name='firstnumber']") as HTMLInputElement;
    const num2 = document.querySelector("input[name='secondnumber']") as HTMLInputElement;
    const result = subtract(Number(num1.value), Number(num2.value));
    const resultElement = document.querySelector("p");
    if (resultElement) {
      resultElement.textContent = result.toString();
    }
}

init();

Затем создайте еще один файл app.ts и добавьте следующий код:

export function subtract(firstnumber: number, secondnumber: number): number {
  return firstnumber - secondnumber;
}

Запуск скрипта dev запустит приложение в режиме разработки:

npm run develop 

Запуск скрипта build запустит приложение в режиме для продакшен сборки:

npm run build

После выполнения команды build Webpack транспилирует два файла TypeScript в код JavaScript и сгенерирует bundle.js в папке dist.

Создание HTML-страниц с помощью HtmlWebpackPlugin

HtmlWebpackPlugin позволяет Webpack генерировать стандартную HTML-страницу, которая будет обслуживать сгенерированные файлы пакета. Когда имя файла пакета изменяется или хэшируется, HTMLWebpackPlugin обновляет имена файлов на HTML-странице. Во-первых, чтобы установить HtmlWebpackPlugin, выполните следующую команду:

npm install html-webpack-plugin --save-dev

Далее нам нужно импортировать и добавить HtmlWebpackPlugin в опцию плагина конфигурации Webpack следующим образом:

const HtmlWebpackPlugin = require("html-webpack-plugin");
const path = require('path');

module.exports = {
  entry: './src/index.ts',
  module: {
    rules: [
      {
        test: /\.ts?$/,
        use: 'ts-loader',
        exclude: /node_modules/,
      }
    ],
  },
  resolve: {
    extensions: ['.tsx', '.ts', '.js'],
  },
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist'),
  },
  plugins: [
    new HtmlWebpackPlugin({
        title: 'our project', 
        template: 'src/custom.html' }) 
  ],
  devServer: {
    static: path.join(__dirname, "dist"),
    compress: true,
    port: 4000,
  },
};

Шаблон представляет собой пользовательский HTML-файл, сгенерированный HtmlWebpackPlugin для вставки в HTML-страницу. Чтобы создать пользовательский HTML-код, внутри папки src создайте custom.html и добавьте следующий HTML-код:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
  </head>
  <body>
    <div class="cal">
      <center>
     <form><br>
      <p>Result : <span id="display"></span></p>
      <input type="number" class="input" placeholder="Enter first number" name="firstnumber" value="1" min="1" min="9" /><br>
      <input type="number" class="input" placeholder="Enter second number" name="secondnumber" value="1" min="1" min="9" /><br><br>
      <button type="submit" class="button">Subtract</button>
    </form>
  </center>
  </div>
  </body>
</html>

Вам не нужно включать скрипт или теги ссылок в пользовательский HTML. HtmlWebpackPlugin позаботится об этом, связав URL-адрес файла пакета со сгенерированной страницей. При запуске приложения в продакшен режиме файл index.html появится внутри папки dist.

Собираем CSS с MiniCSSExtractPlugin

css-loader подсказывает Webpack, как работать с CSS. Он интерпретирует @import и URL как import/require и резолвит их. css-loader позволяет Webpack скомпилировать все CSS файлы и конвертировать их в формат JavaScript. Объединение CSS-файлов с загрузчиком стилей приводит к тому, что стили HTML-страниц не отвечают на запросы до тех пор, пока bundle.js полностью не загружен. Загрузчик стилей внедряет CSS в DOM, но собранный JavaScript файл должен быть полностью загружен до внедрения стилей. Чтобы решить эту проблему, мы можем использовать MiniCssExtractPlugin. MiniCssExtractPlugin извлекает файлы CSS и объединяет их в один bundle.css файл. Это полезно для уменьшения размера ресурсов CSS и помогает избежать ненужных HTTP-запросов для их загрузки. Мы можем установить css-loader и MiniCssExtractPlugin, выполнив в терминале следующие команды:

npm install css-loader --save-dev
npm install mini-css-extract-plugin --save-dev

Теперь давайте добавим css-loader и MiniCssExtractPlugin в webpack.config.js файл. В верхней части webpack.config.js импортируйте модуль MiniCssExtractPlugin, используя приведенный ниже код:

const MiniCssExtractPlugin = require("mini-css-extract-plugin");

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

…
{
        test: /\.css$/,
        use: [MiniCssExtractPlugin.loader, "css-loader"]
}
…

Когда css-loader компилирует все CSS файлы в JavaScript, MiniCssExtractPlugin.loader загружает CSS в CSS бандл. Далее мы добавим MiniCssExtractPlugin в опцию плагина следующим образом:

plugins: [
  new HtmlWebpackPlugin({
    title: 'our project',
    template: 'src/custom.html'
  }),
  new MiniCssExtractPlugin({
    filename:"bundle.css"
  })
]

Теперь, когда мы настроили css-loader и MiniCssExtractPlugin, давайте создадим CSS-файл и импортируем его в index.ts. Внутри папки src создайте index.css и добавьте следующий CSS-код:

form {
    background-color: pink;
    margin-top: 100px;
    border-radius: 40px;
}
.cal {
    width: 550px;
    height: 300px;
    margin-left: 400px;
}
.button {
    border-radius: 10px;
    margin-top: 20px;
    margin-bottom: 20px;
}
.input {
    border-radius: 10px;
    margin-top: 40px;
}

Импортируйте CSS-стиль в index.ts следующим образом:

import styles "./main.css"

Запуск npm run build объединит CSS и применит его к index.html. Когда вы запускаете приложение в режиме разработки и открываете http://localhost:4000.

Минимизация CSS

Мы можем использовать css-minimizer-webpack-plugin, чтобы уменьшить размер файлов CSS, удалив неиспользуемые правила CSS и оставив только необходимые. css-minimizer-webpack-plugin находит все неиспользуемые стили. Затем этот плагин удалит эти неиспользуемые стили из вашего окончательного файла CSS, тем самым уменьшив его размер. Выполните приведенную ниже команду установки, чтобы установить css-minimizer-webpack-plugin:

npm install css-minimizer-webpack-plugin --save-dev

Добавим css-minimizer-webpack-plugin в конфигурацию Webpack. Во-первых, импортируйте плагин следующим образом:

const CssMinimizerPlugin = require("css-minimizer-webpack-plugin");

Затем мы добавим новое свойство optimization в конфигурацию Webpack следующим образом:

optimization: {
  minimizer: [
    new CssMinimizerPlugin()
  ],
}

Когда мы запускаем команду npm run build, bundle.css будет минифицироваться, но bundle.js не будет. Стандартная минификация для bundle.js была переопределена параметром minimizer, который мы установили. Чтобы решить эту проблему, нам нужно минифицировать JavaScript с помощью TerserWebpackPlugin.

Минификация JavaScript

В текущей версии Webpack (на момент написания статьи 5.74.0) и более поздних, вам не нужно устанавливать TerserWebpackPlugin, так как он включен из коробки. Во-первых, мы должны импортировать TerserWebpackPlugin:

const TerserPlugin = require("terser-webpack-plugin");

Затем добавьте TerserPlugin в опцию минимизации следующим образом:

optimization: {
    minimizer: [
      new CssMinimizerPlugin(),
      new TerserPlugin()
    ],
  }

Если вы запустите скрипт npm run build и посмотрите на файлы в папке dist, вы увидите, что и JavaScript, и CSS минифицированы.

Использование CopyWebpackPlugin

Мы можем настроить Webpack для копирования ресурсов приложения из папки c исходными файлами в папку сборки dist с помощью CopyWebpackPlugin. Этот плагин может копировать такие файлы, как изображения, видео и другие ресурсы, в папку dist. Установите CopyWebpackPlugin с помощью следующей команды:

npm install copy-webpack-plugin --save-dev

Теперь добавим CopyWebpackPlugin в конфигурацию Webpack. Импортируйте плагин следующим образом:

const CopyPlugin = require("copy-webpack-plugin");

Далее мы добавим CopyWebpackPlugin в опцию плагина. Свойство from — это папка, из которой мы будем копировать, а to — это папка в каталоге dist, в которую нужно скопировать все файлы:

// ...
plugins: [
  new HtmlWebpackPlugin({
    title: 'our project',
    template: 'src/custom.html'
  }),
  new MiniCssExtractPlugin({
    filename: "bundle.css"
  }),
  new CopyPlugin({
    patterns: [
      { from: "src/img", to: "img" }
    ]
  }),
]
// ...

Создайте новую папку img и добавьте в нее изображения. После выполнения команды npm run build образы будут скопированы в dist/img.

Отладка с помощью source map

Когда мы собираем пакет путем компиляции файлов TypeScript в файлы JavaScript (npm run build), нам может потребоваться отладить и протестировать код с помощью DevTools нашего браузера. При отладке кода инструментам разработки браузера вы заметите, что отображаются только собранные файлы. Всякий раз, когда в нашем коде TypeScript есть ошибка, она будет указана только в собранном файле, что затрудняет отслеживание ошибок в TypeScript для исправления. Тем не менее, с source map кода мы можем легко отлаживать TypeScript с помощью DevTools. Source map кода отображают исходный файл, что упрощает отладку TypeScript и исправление кода и минимизированного кода JavaScript. Файлы .map содержат сведения как об исходных файлах, так и о собранных файлах. DevTools использует этот файл для сопоставления исходного файла с собранным файлом. Чтобы сгенерировать .map для файлов пакета, нам нужно настроить как Webpack, так и TypeScript. В конфигурационном файле TypeScript добавьте sourceMap к параметру компилятора и присвойте ему значение true:

{
    "compilerOptions": {
        "noImplicitAny": true,
        "target": "ES5",
        "module": "ES2015",
        "sourceMap": true
    }
}

Далее мы добавим свойство devtool в конфигурацию Webpack и установим его в true, указав Webpack сгенерировать соответствующую карту исходного кода для каждого собранного файла:

module.exports = {
  devtool: 'source-map',
  // ...
}

Выполнив команду npm run build, вы сможете отлаживать исходный код напрямую.

Итоги

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

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