Cloudflare обновила стек Workers: меньше падений wrangler, аккуратная работа с Uint8Array и новый пакет autoconfig — VogueTech

Что нового

Cloudflare выкатил серию обновлений для своего стека вокруг Workers. Главный релиз — wrangler@4.103.0, вместе с ним обновились miniflare, create-cloudflare, @cloudflare/workers-utils и ещё несколько вспомогательных пакетов.

Ключевые изменения:

Wrangler 4.103.0
- Функция unstable_getWorkerNameFromProject переехала из wrangler в пакет @cloudflare/workers-utils и теперь называется getWorkerNameFromProject (без префикса unstable_).
- Cloudflare полностью вынесла экспериментальный автоконфиг в отдельный пакет @cloudflare/autoconfig. Старые экспорты experimental_getDetailsForAutoConfig, experimental_runAutoConfig, experimental_AutoConfigFramework удалены из wrangler.
- Исправлена резолюция относительных импортов с { type: "cf-worker" } в cloudflare.config.ts: теперь путь считается относительно модуля, где написан импорт, а не относительно корневого конфига.
- wrangler dev перестал падать при некорректной колонке в source map, когда поток ошибок обрывается на середине stack trace.
- В локальных Workflows Uint8Array больше не сохраняется с полной ArrayBuffer, что убирает ошибку SQLITE_TOOBIG при размерах ниже лимита 1 MiB.
Miniflare 4.20260617.1
- Наследует фикс с Uint8Array в локальных Workflows, синхронизируя поведение с production.
create-cloudflare@2.70.5 (C3)
- Исправлен бесконечный цикл при запуске через pnpm 11 (pnpm create cloudflare@latest), связанный с политикой minimumReleaseAge и автообновлением C3.
@cloudflare/workers-utils@0.24.0
- Перенос getWorkerNameFromProject из wrangler.
- Добавлен интерфейс PackageManager и константы для менеджеров пакетов: NpmPackageManager, PnpmPackageManager, YarnPackageManager, BunPackageManager.
@cloudflare/workers-auth@0.3.2
- Обновлена зависимость на @cloudflare/workers-utils@0.24.0.
@cloudflare/vitest-pool-workers@0.16.18
- Подтянул обновления wrangler@4.103.0 и miniflare@4.20260617.1.
@cloudflare/vite-plugin@1.42.1
- Использует новый механизм резолюции относительных cf-worker-entrypoint импортов.
- Обновлён до wrangler@4.103.0 и miniflare@4.20260617.1.
@cloudflare/pages-shared@0.13.148
- Обновлён до miniflare@4.20260617.1.
@cloudflare/deploy-helpers@0.2.2
- Перенос логики провижининга ресурсов (bindings) из wrangler в общий слой deploy-helpers для деплоя и загрузки версий.
- Обновления зависимостей: miniflare@4.20260617.1, @cloudflare/workers-utils@0.24.0, @cloudflare/cli-shared-helpers@0.1.10.
@cloudflare/cli-shared-helpers@0.1.10
- Обновлён до @cloudflare/workers-utils@0.24.0.

Цифровые параметры, которые здесь важны:

Лимит размера вывода шага Workflow — 1 MiB. До фикса Uint8Array мог падать задолго до этого лимита.
Типичный проблемный кейс из описания: 200 KB view из 800 KB буфера (crypto.getRandomValues или slice от большого пула) раньше приводил к SQLITE_TOOBIG.
pnpm 11 по умолчанию включает защиту minimumReleaseAge, которая блокирует установку пакетов, опубликованных менее 24 часов назад. Это и ломало автообновление C3.

Как это работает

Перенос getWorkerNameFromProject в @cloudflare/workers-utils

Раньше wrangler экспортировал функцию unstable_getWorkerNameFromProject, которая вычисляла имя воркера по проекту. Теперь:

Экспорт удалён из wrangler.
Функция живёт в @cloudflare/workers-utils под именем getWorkerNameFromProject.
Префикс unstable_ убрали, но саму логику не описывают подробно — для разработчика важен перенос и точка импорта.

Это разгружает wrangler и выносит утилитарные вещи в отдельный пакет, который можно переиспользовать в других CLI и тулзах.

Новый пакет @cloudflare/autoconfig

Ранее wrangler содержал экспериментальные экспорты:

experimental_getDetailsForAutoConfig
experimental_runAutoConfig
experimental_AutoConfigFramework

Теперь вся эта логика уехала в отдельный пакет @cloudflare/autoconfig. Префиксы experimental_ сняты, потому что весь пакет пока pre-v1. Это значит:

Автоконфиг больше не размазан по wrangler.
Любой инструмент может работать с автоконфигом через единый пакет, а не через приватные экспериментальные API wrangler.

Резолюция cf-worker entrypoint в cloudflare.config.ts

В экспериментальном cloudflare.config.ts можно импортировать entrypoint воркера так:

import worker from "./src/index.ts" with { type: "cf-worker" };
``

Проблема: раньше относительный путь `./src/index.ts` передавался дальше как есть и потом резолвился относительно **верхнеуровневого конфиг-файла**, а не того файла, где написан импорт.

Это ломало конфиги, которые реэкспортируют воркеры из вложенных файлов. Теперь Cloudflare:

- Привязывает относительный путь к **модулю-импортеру**.
- Оставляет без изменений:
  - bare specifiers вида `@scope/pkg`;
  - виртуальные модули вида `virtual:foo`.

Резолюцию таких импортов Cloudflare отдаёт на сторону потребителя (например, сборщика).

### Обработка ошибок в wrangler dev и source maps

Когда воркер за короткое время пишет много ошибок в stderr, `wrangler dev` получает чанки лога. Иногда чанк обрывается **посреди stack frame**. В этом случае:

- В логе остаётся вызов с некорректным номером колонки.
- Библиотека для работы с source map выбрасывает исключение.
- Из-за этого падал весь процесс `wrangler`.

Теперь `wrangler` ловит это исключение и:

- Возвращает оригинальный текст ошибки **без** source map.
- Не завершает работу dev-сервера.

### Uint8Array и SQLITE_TOOBIG в локальных Workflows

Сценарий до фикса:

- Шаг Workflow под `wrangler dev` возвращает `Uint8Array`.
- При сериализации в локальную базу вместе с view сохраняется **весь** исходный `ArrayBuffer`.
- Если исходный буфер крупный (например, 800 KB), а view всего 200 KB, в базу всё равно уезжают 800 KB.
- SQLite выбрасывает `SQLITE_TOOBIG` задолго до лимита 1 MiB для step-output.

Теперь Cloudflare:

- Перед сохранением копирует байты view в **плотный буфер** нужного размера.
- Сохраняет только фактические байты view, а не весь backing buffer.
- Выравнивает локальное поведение с production.

### C3 и бесконечный цикл с pnpm 11

Поведение C3 (`create-cloudflare`):

- При запуске через `pnpm create cloudflare@latest` C3 проверяет npm на наличие более свежей версии.
- Если находит новую, перезапускает себя с этой версией.

С появлением `pnpm 11` и политики `minimumReleaseAge`:

- `pnpm` **не устанавливает** версии, опубликованные менее 24 часов назад.
- `npm latest` может указывать на свежую версию, которую `pnpm` не готов поставить.
- Проверка обновления всегда говорит «есть новая версия», C3 перезапускается снова и снова.

Cloudflare добавила маркер для перезапущенного процесса:

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

### Deploy helpers и провижининг ресурсов

Раньше `wrangler` отвечал за провижининг bindings (KV, Durable Objects и прочее) при деплое и загрузке версий. Теперь Cloudflare:

- Вынесла эту логику в `@cloudflare/deploy-helpers`.
- И `deploy`, и `versions upload` используют один и тот же механизм.
- Уменьшилось количество специфичных для `wrangler` колбэков, при этом поведение для разработчика сохранилось.

### PackageManager в workers-utils

`@cloudflare/workers-utils@0.24.0` добавил:

- Интерфейс `PackageManager`.
- Константы: `NpmPackageManager`, `PnpmPackageManager`, `YarnPackageManager`, `BunPackageManager`.

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

## Что это значит для вас

### Если вы пишете на Cloudflare Workers

- **Обновите импорты:**
  - Если вы тянули `unstable_getWorkerNameFromProject` из `wrangler`, переключитесь на:

    ```ts
    import { getWorkerNameFromProject } from "@cloudflare/workers-utils";
    ```

- **Проверьте конфиги:**
  - Если вы используете экспериментальный `cloudflare.config.ts` и импортируете воркеры с `{ type: "cf-worker" }`, теперь резолюция привязана к файлу-импортеру.
  - Это исправляет странные баги с реэкспортами из вложенных файлов, но может поменять поведение там, где вы случайно опирались на старую логику.

- **Меньше падений dev-сервера:**
  - При бурстах ошибок `wrangler dev` больше не вылетает из-за кривых source maps. Вы теряете красивый mapped stack trace, но не теряете сессию разработки.

### Если вы используете Workflows и работаете с бинарными данными

- Возвращать `Uint8Array` из шагов Workflow под `wrangler dev` теперь безопаснее.
- Типичный сценарий:
  - Генерируете большой буфер через `crypto.getRandomValues`.
  - Берёте слайс `arr.slice(...)` и возвращаете его.
- Раньше даже 200 KB view из 800 KB буфера могло уронить локальную SQLite с `SQLITE_TOOBIG`.
- Теперь Cloudflare сохраняет только фактические байты view, и поведение соответствует production-лимиту 1 MiB.

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

### Если вы поднимаете проекты через create-cloudflare (C3)

- Запуск `pnpm create cloudflare@latest` с `pnpm 11` теперь не зациклится.
- Даже если `npm latest` указывает на версию моложе 24 часов, C3 максимум один раз попробует обновиться и потом просто стартует.
- Это особенно полезно, если вы разворачиваете шаблоны в CI/CD или на новых машинах, где по умолчанию стоит свежий `pnpm`.

### Если вы пишете свои тулзы вокруг Workers

- Логика автоконфига теперь лежит в `@cloudflare/autoconfig`.
- Утилиты для работы с воркерами, именами проектов и менеджерами пакетов — в `@cloudflare/workers-utils`.
- Провижининг ресурсов при деплое — в `@cloudflare/deploy-helpers`.

Практический вывод: проще строить собственные CLI, генераторы и обёртки вокруг Workers, не залезая в приватные детали `wrangler`.

### Доступность из России

Cloudflare Workers и сопутствующие пакеты официально доступны. Однако:

- Установка идёт через npm-регистры и GitHub. Если у вас ограничен доступ к этим ресурсам, может понадобиться VPN или прокси.
- Поведение менеджеров пакетов (`npm`, `pnpm`, `yarn`, `bun`) зависит от локальной конфигурации и зеркал.

## Место на рынке

Эти релизы не про новые функции воркеров, а про устойчивость и предсказуемость экосистемы вокруг них.

По сути, Cloudflare делает три вещи:

- Централизует общую логику в отдельных пакетах (`@cloudflare/autoconfig`, `@cloudflare/deploy-helpers`, `@cloudflare/workers-utils`).
- Снимает острые углы для разработчиков: падения `wrangler dev`, странные ошибки SQLite, циклы автообновления.
- Синхронизирует поведение локальных инструментов с production (Workflows, step-output, резолюция entrypoint).

Прямых численных сравнений с альтернативами здесь нет — это инфраструктурное обновление внутри экосистемы Cloudflare. Для разработчика, который уже выбрал Workers, это шаг в сторону более предсказуемого DX и меньшего количества «магических» багов.

## Установка / Как запустить

Ниже — базовые команды для обновления и использования затронутых пакетов. Конкретные версии берите из релиза, описанного выше.

### Обновление wrangler до 4.103.0

```bash
npm install -D wrangler@4.103.0
# или
pnpm add -D wrangler@4.103.0
# или
yarn add -D wrangler@4.103.0

Если вы использовали unstable_getWorkerNameFromProject, поменяйте импорт:

// было
import { unstable_getWorkerNameFromProject } from "wrangler";

// стало
import { getWorkerNameFromProject } from "@cloudflare/workers-utils";

Установка @cloudflare/workers-utils и @cloudflare/autoconfig

npm install -D @cloudflare/workers-utils@0.24.0 @cloudflare/autoconfig
# или
pnpm add -D @cloudflare/workers-utils@0.24.0 @cloudflare/autoconfig

Пример использования PackageManager (концептуально, без конкретной реализации из исходников):

import {
  NpmPackageManager,
  PnpmPackageManager,
  YarnPackageManager,
  BunPackageManager,
} from "@cloudflare/workers-utils";

// Выбор менеджера пакетов по окружению
const pm = process.env.PACKAGE_MANAGER === "pnpm"
  ? PnpmPackageManager
  : process.env.PACKAGE_MANAGER === "yarn"
  ? YarnPackageManager
  : process.env.PACKAGE_MANAGER === "bun"
  ? BunPackageManager
  : NpmPackageManager;

pm.install({ dev: true, packages: ["wrangler@4.103.0"] });

Запуск create-cloudflare (C3) с pnpm 11

pnpm create cloudflare@latest

Теперь C3:

Проверит наличие новой версии.
При необходимости один раз перезапустится.
Больше не зациклится из-за ограничений minimumReleaseAge.

Локальная разработка с miniflare и Workflows

Обновите miniflare до версии из релиза:

npm install -D miniflare@4.20260617.1
# или
pnpm add -D miniflare@4.20260617.1

Теперь шаги Workflow, которые возвращают Uint8Array, будут вести себя локально так же, как в production, без неожиданных SQLITE_TOOBIG при размерах меньше 1 MiB.