Cloudflare Workers перестроил модульную систему для Node.js: что изменилось для разработчиков

9 сентября 2026 года Cloudflare объявил о новой реализации module registry в workerd — открытом ядре среды выполнения Cloudflare Workers. Компания переписала механизм разрешения, загрузки и кеширования модулей, чтобы сделать его ближе к поведению Node.js и веб-стандартам.

Это не просто внутренняя оптимизация. Для приложений, которые используют Node.js API, ESM, CommonJS, WebAssembly или сложные зависимости, правила работы с модулями определяют, насколько предсказуемо код переносится между локальной средой и Workers.

Что Cloudflare изменил в module registry

По официальному анонсу новый registry использует URL как основу для module specifiers, поддерживает import.meta.url, import.meta.main и import.meta.resolve(), корректнее работает с node:-модулями, import attributes и require() для ES modules.

Cloudflare также сообщил о ленивой компиляции модулей: код компилируется при первом реальном импорте, а не обязательно весь заранее. Для WebAssembly добавлена поддержка source phase imports.

Первичный источник — официальный Cloudflare Blog от 9 сентября 2026 года.

Почему URL-based resolution имеет значение

Старый registry в Workers трактовал specifiers скорее как пути файловой системы. Новый подход начинает с URL. Из-за этого относительные импорты разрешаются по тем же базовым правилам, что и new URL(specifier, base).

Практическое следствие — query strings и fragments становятся частью идентичности модуля. Два импорта одного исходного файла с разными query parameters могут рассматриваться как разные экземпляры. Это поведение соответствует модели модулей в браузерах и делает правила более последовательными.

Что появилось в import.meta

import.meta.url теперь позволяет модулю узнать собственный URL. import.meta.main показывает, является ли текущий модуль entrypoint Worker, а import.meta.resolve() разрешает specifier относительно текущего модуля без фактического импорта.

Для библиотек, которые ожидают Node.js-подобное поведение, это уменьшает число специальных обходов. Особенно это заметно в пакетах, где пути к ресурсам или соседним модулям вычисляются динамически.

Как изменился require() для ES modules

Новая реализация следует правилам Node.js для require(esm). Если ES module экспортирует значение с именем module.exports, оно возвращается через require(); иначе возвращается namespace object. Для встроенных модулей workerd предусмотрено совместимое поведение.

При этом синхронный require() не может корректно вернуть модуль, граф которого содержит top-level await. В таком случае, как и в Node.js, требуется асинхронный import().

Import attributes теперь валидируются строже

Старое поведение могло игнорировать часть import attributes. Новый registry валидирует их. Для JSON поддерживается with { type: 'json' }, а неподдерживаемые атрибуты или несоответствие типа модуля должны приводить к ошибке вместо молчаливого игнорирования.

Для разработчика это полезнее, хотя на этапе миграции может обнаружить код, который раньше работал только из-за более мягкой обработки.

Ленивая компиляция и кеширование

Cloudflare отмечает, что прежняя реализация могла компилировать весь bundle заранее и держать отдельные копии данных для разных V8 isolates. Новый registry проектировался с учётом lazy compilation и возможности более эффективного переиспользования кода.

Это архитектурное изменение не означает, что любой Worker автоматически станет быстрее. Эффект зависит от структуры приложения, числа модулей и путей выполнения. Но сама модель даёт runtime больше пространства для оптимизаций.

Как включить новый module registry

Cloudflare предлагает включить compatibility flag new_module_registry. На момент анонса у него нет даты, после которой он включается автоматически, поэтому разработчику нужно добавить флаг явно.

{
  "compatibility_flags": ["new_module_registry"]
}

Для production-проекта разумно сначала включить флаг в тестовом окружении и прогнать критические сценарии: загрузку Worker, динамические импорты, CommonJS-зависимости, работу npm-пакетов и WebAssembly, если он используется.

Почему это важно для экосистемы Node.js на Workers

Совместимость с Node.js состоит не только из наличия отдельных API. Реальное приложение зависит от того, как runtime понимает ESM и CommonJS, как разрешает пути, идентифицирует один и тот же модуль и кеширует его.

Именно поэтому новая модульная система может оказаться важнее, чем очередное добавление нескольких API. Она затрагивает базовый слой, на котором работают фреймворки, библиотеки и bundlers.

Что это меняет для разработчика

Если проект уже работает на Workers без проблем, срочно менять конфигурацию не обязательно. Cloudflare прямо пишет, что существующий registry продолжает работать. Новый вариант сейчас полезнее рассматривать как opt-in режим для тестирования совместимости и новых сценариев.

Если же приложение переносится с Node.js, использует сложный module graph или зависимости, чувствительные к import.meta и правилам ESM/CommonJS, новый registry может убрать часть несовместимостей. Но каждую конкретную зависимость всё равно нужно проверять.

Связь с другими изменениями Cloudflare Workers

Cloudflare в последние месяцы расширяет Node.js-совместимость Workers и возможности более крупных приложений. Ранее я разбирал увеличение лимита Worker до 64 MiB. Новый module registry продолжает ту же линию: сделать runtime удобнее для более сложных серверных приложений.

Что проверить перед включением

Перед переходом стоит зафиксировать текущую рабочую конфигурацию, обновить тесты и отдельно проверить зависимости, которые используют динамические импорты, CommonJS, top-level await, JSON modules или собственное разрешение путей.

Если проект использует Workers как часть более большой архитектуры, полезно проверять изменения вместе с frontend, API и CI/CD. В A.S Groups я занимаюсь веб-разработкой и доработкой проектов, а также интеграциями и автоматизацией, где edge-runtime может быть отдельным слоем системы.

Вывод

Новая модульная система Cloudflare Workers — это фундаментальное изменение уровня runtime. Она приближает разрешение и загрузку модулей к Node.js и веб-стандартам, добавляет полноценный import.meta, уточняет правила ESM/CommonJS и меняет стратегию компиляции.

Пока новый registry включается явно, поэтому лучший подход — не активировать его вслепую, а протестировать на конкретном проекте. Для новых Node.js-ориентированных Workers это особенно интересное обновление, потому что оно улучшает не отдельный API, а сам механизм работы модулей.