Переход с Rollup 3 на Rollup 4

Выход Rollup 4 стал одним из наиболее значимых обновлений за всю историю проекта. Новая версия принесла существенные изменения в архитектуру сборщика, повысила производительность, изменила работу некоторых API и пересмотрела ряд внутренних механизмов.

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

Основные причины перехода:

  • ускорение процесса сборки;
  • уменьшение времени запуска;
  • улучшение механизма обработки модулей;
  • обновлённая система работы с бинарными пакетами;
  • поддержка современных версий Node.js;
  • дальнейшее развитие экосистемы плагинов.

Основные изменения в Rollup 4

Версия Rollup 4 содержит несколько категорий изменений:

Изменения производительности

Одной из главных целей разработчиков было ускорение работы сборщика.

В Rollup 4:

  • ускорен анализ графа зависимостей;
  • оптимизировано дерево зависимостей (tree shaking);
  • улучшена генерация выходного кода;
  • сокращены накладные расходы на запуск процесса сборки.

На крупных проектах время сборки может уменьшаться на десятки процентов по сравнению с Rollup 3.


Использование нативных бинарных пакетов

Одним из наиболее заметных нововведений стало появление платформенно-зависимых бинарных сборок.

Ранее Rollup распространялся в основном как JavaScript-пакет. В четвёртой версии появились предварительно собранные бинарные модули для различных платформ:

  • Linux;
  • Windows;
  • macOS;
  • архитектуры x64;
  • ARM64 и другие.

Это позволило ускорить запуск и выполнение внутренних операций.

После установки в каталоге зависимостей могут появляться дополнительные платформенные пакеты.

Например:

{
  "optionalDependencies": {
    "@rollup/rollup-linux-x64-gnu": "4.x"
  }
}

Подобные пакеты обычно устанавливаются автоматически и не требуют ручной настройки.


Требования к Node.js

Одним из первых шагов при миграции является проверка версии Node.js.

Rollup 4 отказался от поддержки старых выпусков Node.js.

Перед обновлением необходимо убедиться, что среда выполнения соответствует требованиям новой версии.

Проверка версии:

node -v

Обновление Rollup без обновления Node.js нередко приводит к ошибкам запуска, проблемам установки зависимостей или невозможности выполнения сборки.


Обновление пакета Rollup

Базовое обновление выполняется стандартным способом.

Для npm:

npm install rollup@latest --save-dev

Для Yarn:

yarn add rollup@latest --dev

Для pnpm:

pnpm add rollup@latest -D

После установки желательно полностью удалить старые зависимости и выполнить чистую установку:

rm -rf node_modules
rm package-lock.json

npm install

Либо аналогичные действия для используемого менеджера пакетов.


Проверка совместимости плагинов

После обновления самого Rollup необходимо проверить плагины.

Наиболее часто используемые плагины:

  • @rollup/plugin-node-resolve;
  • @rollup/plugin-commonjs;
  • @rollup/plugin-json;
  • @rollup/plugin-replace;
  • @rollup/plugin-typescript;
  • @rollup/plugin-babel.

Большинство официальных плагинов получили поддержку Rollup 4, однако старые версии могут вызывать предупреждения или ошибки.

Пример обновления:

npm update @rollup/plugin-node-resolve
npm update @rollup/plugin-commonjs

Либо:

npm install @rollup/plugin-node-resolve@latest
npm install @rollup/plugin-commonjs@latest

Изменения в API плагинов

Разработчики собственных плагинов должны уделить особое внимание изменениям внутренних API.

Некоторые устаревшие возможности были удалены либо изменили поведение.

Типичный сценарий:

Rollup 3

export default function myPlugin() {
  return {
    name: 'my-plugin',

    transform(code) {
      return code;
    }
  };
}

Rollup 4

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

Поэтому рекомендуется внимательно проверять:

  • хуки жизненного цикла;
  • обработчики модулей;
  • генерацию чанков;
  • доступ к метаданным сборки.

Изменения в обработке предупреждений

В Rollup 4 некоторые предупреждения были переработаны.

Например:

export default {
  onwarn(warning, warn) {
    warn(warning);
  }
};

Старые фильтры предупреждений могут перестать работать корректно, если логика основывалась на прежних кодах предупреждений.

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


Пересмотр кодов предупреждений

Некоторые коды предупреждений были переименованы, уточнены либо получили дополнительную информацию.

Например, логика обработки:

onwarn(warning, warn) {
  if (warning.code === 'CIRCULAR_DEPENDENCY') {
    return;
  }

  warn(warning);
}

После обновления рекомендуется проверить:

  • актуальность кодов предупреждений;
  • необходимость существующих фильтров;
  • корректность пользовательской логики логирования.

Изменения в механизме watch

Режим наблюдения за файлами продолжает работать по прежнему принципу:

rollup -c -w

Однако внутренняя реализация была оптимизирована.

На крупных проектах можно заметить:

  • более быстрые повторные сборки;
  • уменьшение потребления памяти;
  • более стабильную работу при большом количестве файлов.

Если проект использует собственные расширения для watch-режима, необходимо проверить их совместимость отдельно.


Обновление TypeScript-проектов

Для проектов на TypeScript миграция обычно сводится к обновлению связанных зависимостей.

Пример:

npm install \
typescript \
@rollup/plugin-typescript \
rollup \
--save-dev

Конфигурация зачастую остаётся прежней:

import typescript from '@rollup/plugin-typescript';

export default {
  input: 'src/index.ts',

  output: {
    file: 'dist/index.js',
    format: 'es'
  },

  plugins: [
    typescript()
  ]
};

Тем не менее рекомендуется убедиться, что версия TypeScript совместима с используемой версией плагина.


Обновление Babel-интеграции

При использовании Babel желательно обновить все связанные пакеты одновременно:

npm install \
@rollup/plugin-babel \
@babel/core \
@babel/preset-env \
--save-dev

Конфигурация обычно остаётся без изменений:

babel({
  babelHelpers: 'bundled'
})

Однако старые версии Babel-плагинов могут содержать зависимости от API Rollup 3.


Изменения в генерации чанков

В Rollup 4 была улучшена логика формирования чанков.

Конфигурации вида:

export default {
  output: {
    manualChunks: {
      vendor: ['react']
    }
  }
};

обычно продолжают работать без изменений.

Однако на практике возможно изменение структуры выходных файлов из-за улучшенного анализа графа зависимостей.

Поэтому после миграции желательно проверить:

  • размер файлов;
  • состав чанков;
  • порядок загрузки модулей;
  • корректность динамического импорта.

Проверка tree shaking

Rollup известен качественным удалением неиспользуемого кода.

После перехода на Rollup 4 рекомендуется сравнить результаты сборки:

rollup -c

Особое внимание следует уделить:

  • библиотекам с побочными эффектами;
  • динамическим импортам;
  • CommonJS-модулям;
  • пользовательским плагинам трансформации.

Иногда улучшенный анализ зависимостей приводит к изменению структуры итогового бандла.


Возможные проблемы после обновления

Несовместимые плагины

Самая распространённая проблема:

Plugin is incompatible with Rollup 4

Причина обычно заключается в использовании устаревшей версии плагина.

Решение:

  • обновить плагин;
  • проверить changelog;
  • заменить заброшенный пакет современным аналогом.

Ошибки установки бинарных пакетов

Иногда могут возникать сообщения:

Cannot find module
@rollup/rollup-linux-x64-gnu

Чаще всего помогает:

rm -rf node_modules
npm install

Либо повторная установка зависимостей с очисткой кэша менеджера пакетов.


Ошибки пользовательских плагинов

Если проект содержит собственный Rollup-плагин:

export default function customPlugin() {
  return {
    name: 'custom',

    generateBundle() {
      console.log('bundle generated');
    }
  };
}

Необходимо проверить:

  • корректность сигнатур методов;
  • использование контекста плагина;
  • обращения к внутренним API Rollup;
  • работу с объектами метаданных.

Большинство проблем миграции возникает именно в самописных расширениях.


Рекомендуемая последовательность миграции

Шаг 1. Обновление Node.js

Проверяется соответствие требованиям новой версии Rollup.

Шаг 2. Обновление Rollup

npm install rollup@latest --save-dev

Шаг 3. Обновление официальных плагинов

npm update @rollup/plugin-*

Шаг 4. Очистка зависимостей

rm -rf node_modules
npm install

Шаг 5. Проверка сборки

npm run build

Шаг 6. Проверка watch-режима

npm run dev

Шаг 7. Анализ предупреждений

Проверяются новые сообщения, изменившиеся коды предупреждений и потенциальные проблемы совместимости.

Шаг 8. Проверка итогового бандла

Анализируются:

  • размер файлов;
  • дерево зависимостей;
  • корректность чанков;
  • динамические импорты;
  • работа в браузере и Node.js.

Практический пример миграции

Конфигурация Rollup 3:

import resolve from '@rollup/plugin-node-resolve';
import commonjs from '@rollup/plugin-commonjs';

export default {
  input: 'src/index.js',

  output: {
    file: 'dist/bundle.js',
    format: 'esm',
    sourcemap: true
  },

  plugins: [
    resolve(),
    commonjs()
  ]
};

После перехода на Rollup 4 конфигурация в большинстве случаев остаётся неизменной:

import resolve from '@rollup/plugin-node-resolve';
import commonjs from '@rollup/plugin-commonjs';

export default {
  input: 'src/index.js',

  output: {
    file: 'dist/bundle.js',
    format: 'esm',
    sourcemap: true
  },

  plugins: [
    resolve(),
    commonjs()
  ]
};

Основные изменения обычно затрагивают не сам конфигурационный файл, а:

  • версии зависимостей;
  • пользовательские плагины;
  • интеграции со сторонними инструментами;
  • требования к версии Node.js.

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