Выход Rollup 4 стал одним из наиболее значимых обновлений за всю историю проекта. Новая версия принесла существенные изменения в архитектуру сборщика, повысила производительность, изменила работу некоторых API и пересмотрела ряд внутренних механизмов.
Для большинства проектов переход с Rollup 3 на Rollup 4 не является сложным, однако требует понимания несовместимых изменений, обновления плагинов и проверки существующей конфигурации.
Основные причины перехода:
Версия Rollup 4 содержит несколько категорий изменений:
Одной из главных целей разработчиков было ускорение работы сборщика.
В Rollup 4:
На крупных проектах время сборки может уменьшаться на десятки процентов по сравнению с Rollup 3.
Одним из наиболее заметных нововведений стало появление платформенно-зависимых бинарных сборок.
Ранее Rollup распространялся в основном как JavaScript-пакет. В четвёртой версии появились предварительно собранные бинарные модули для различных платформ:
Это позволило ускорить запуск и выполнение внутренних операций.
После установки в каталоге зависимостей могут появляться дополнительные платформенные пакеты.
Например:
{
"optionalDependencies": {
"@rollup/rollup-linux-x64-gnu": "4.x"
}
}
Подобные пакеты обычно устанавливаются автоматически и не требуют ручной настройки.
Одним из первых шагов при миграции является проверка версии Node.js.
Rollup 4 отказался от поддержки старых выпусков Node.js.
Перед обновлением необходимо убедиться, что среда выполнения соответствует требованиям новой версии.
Проверка версии:
node -v
Обновление Rollup без обновления Node.js нередко приводит к ошибкам запуска, проблемам установки зависимостей или невозможности выполнения сборки.
Базовое обновление выполняется стандартным способом.
Для 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.
Некоторые устаревшие возможности были удалены либо изменили поведение.
Типичный сценарий:
export default function myPlugin() {
return {
name: 'my-plugin',
transform(code) {
return code;
}
};
}
Большая часть подобных конструкций продолжает работать, однако отдельные методы могут получать дополнительные параметры или возвращать данные в изменённом формате.
Поэтому рекомендуется внимательно проверять:
В Rollup 4 некоторые предупреждения были переработаны.
Например:
export default {
onwarn(warning, warn) {
warn(warning);
}
};
Старые фильтры предупреждений могут перестать работать корректно, если логика основывалась на прежних кодах предупреждений.
Поэтому после миграции полезно выполнить полную сборку и проверить список выводимых сообщений.
Некоторые коды предупреждений были переименованы, уточнены либо получили дополнительную информацию.
Например, логика обработки:
onwarn(warning, warn) {
if (warning.code === 'CIRCULAR_DEPENDENCY') {
return;
}
warn(warning);
}
После обновления рекомендуется проверить:
Режим наблюдения за файлами продолжает работать по прежнему принципу:
rollup -c -w
Однако внутренняя реализация была оптимизирована.
На крупных проектах можно заметить:
Если проект использует собственные расширения для watch-режима, необходимо проверить их совместимость отдельно.
Для проектов на 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 желательно обновить все связанные пакеты одновременно:
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']
}
}
};
обычно продолжают работать без изменений.
Однако на практике возможно изменение структуры выходных файлов из-за улучшенного анализа графа зависимостей.
Поэтому после миграции желательно проверить:
Rollup известен качественным удалением неиспользуемого кода.
После перехода на Rollup 4 рекомендуется сравнить результаты сборки:
rollup -c
Особое внимание следует уделить:
Иногда улучшенный анализ зависимостей приводит к изменению структуры итогового бандла.
Самая распространённая проблема:
Plugin is incompatible with Rollup 4
Причина обычно заключается в использовании устаревшей версии плагина.
Решение:
Иногда могут возникать сообщения:
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');
}
};
}
Необходимо проверить:
Большинство проблем миграции возникает именно в самописных расширениях.
Проверяется соответствие требованиям новой версии Rollup.
npm install rollup@latest --save-dev
npm update @rollup/plugin-*
rm -rf node_modules
npm install
npm run build
npm run dev
Проверяются новые сообщения, изменившиеся коды предупреждений и потенциальные проблемы совместимости.
Анализируются:
Конфигурация 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()
]
};
Основные изменения обычно затрагивают не сам конфигурационный файл, а:
Именно поэтому для большинства современных проектов миграция с Rollup 3 на Rollup 4 представляет собой эволюционное обновление с акцентом на повышение производительности, улучшение внутренней архитектуры и подготовку инфраструктуры сборки к дальнейшему развитию экосистемы Rollup.