← Cloudflare Workers / workers / wrangler

Устаревшие функции

Ознакомьтесь с различиями между версиями Wrangler, в частности с устаревшими и критическими изменениями.

Использование Workers Sites считается устаревшим. Вместо этого мы рекомендуем перейти на Workers Static Assets. Поддержка Workers Sites в Wrangler будет удалена в одной из будущих версий Wrangler.

Использование Service Environments ↗, включено через legacy_env свойство в конфигурации Wrangler, устарело. Взамен рекомендуем перейти на Окружения Wrangler. Поддержка Service Environments в Wrangler будет удалена в одной из будущих версий Wrangler.

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

wrangler generate команда устарела, но всё ещё работает в v3. wrangler generate будет полностью удалён в v4.

Используйте npm create cloudflare@latest для новых проектов Workers и Pages.

wrangler publish команда устарела, но всё ещё работает в v3. wrangler publish будет полностью удалён в v4.

Используйте npx wrangler deploy чтобы развернуть Workers.

wrangler pages publish команда устарела, но всё ещё работает в v3. wrangler pages publish будет полностью удалён в v4.

Используйте wrangler pages deploy чтобы развернуть Pages.

Вместо этого используйте wrangler --version чтобы проверить текущую версию Wrangler.

wrangler dev в v3 по умолчанию является локальным, поэтому этот параметр больше не нужен.

wrangler dev в v3 по умолчанию является локальным, поэтому этот параметр больше не нужен.

wrangler dev по умолчанию автоматически сохраняет данные, поэтому эта опция больше не нужна.

Эти параметры предотвращают wrangler pages dev точно эмулировать поведение production при раздаче статических ресурсов, поэтому они были признаны устаревшими. Вместо того чтобы полагаться на проксирование Wrangler через какой-то другой сторонний dev-сервер, вы можете добиться более точной эмуляции, собрав статические ресурсы в каталог и указав Wrangler на этот каталог с помощью wrangler pages dev <directory>.

Мы рекомендуем переход на Workers assets ↗

Вместо этого используйте nodejs_compat флаг совместимости ↗. Сюда входит функциональность из устаревшего node_compat полифиллы и нативно реализованные Node.js API.

Это больше не имеет эффекта после развертывание Workers Standard Pricing ↗.

Wrangler v2 добавляет новые поля конфигурации и новые функции для разработки и развёртывания Worker, а также помечает некоторые избыточные поля как устаревшие.

• wrangler.toml больше не является обязательным.
• dev и publish принимает аргументы командной строки.
• tail можно запускать под произвольными именами Worker.
• init создаёт шаблон проекта.
• JSON-привязки для vars.
• Локальный режим для wrangler dev.
• Система модулей (для форматов Workers modules и service worker).
• DevTools.
• Поддержка TypeScript.
• Предоставление доступа к среде разработки в интернете.
• Более широкая совместимость с платформами.
• Горячие клавиши разработчика.
• Улучшенная проверка конфигурации.

В следующем видео рассказывается об основных изменениях в Wrangler v2 и показано, как Wrangler v2 может ускорить вашу работу.

Список часто встречающихся полей, которые больше не требуются, приведён ниже.

• type больше не требуется. Wrangler автоматически определит правильный тип проекта.
• zone_id больше не требуется. Его можно определить непосредственно из маршрутов.
• build.upload.format больше не используется. Формат теперь определяется автоматически по коду.
• build.upload.main и build.upload.dir больше не требуются. Используйте верхнеуровневый main поле, которое теперь служит точкой входа для Worker.
• site.entry-point больше не требуется. Точку входа следует указывать через main поле.
• webpack_config и webpack свойства больше не поддерживаются. См. Перенос проектов на базе webpack с Wrangler версии 1. Ниже приведены команды Wrangler v1, которые больше не поддерживаются:
• wrangler preview - Используйте wrangler dev команду, чтобы запустить Worker в локальном окружении.
• wrangler generate - Если вы хотите использовать стартовый шаблон, склонируйте его репозиторий GitHub и инициализируйте вручную.
• wrangler route - Маршруты определяются в конфигурационный файл Wrangler.
• wrangler report - Если вы обнаружили ошибку, сообщите о ней на Проблемы Wrangler ↗.
• wrangler build - Если вам нужен доступ к результату сборки Worker, используйте wrangler deploy --outdir=path/to/output.

Это новые поля, которые можно добавить в ваш конфигурационный файл Wrangler.

• main: string, необязательно

  main поле используется для указания точки входа Worker. Она может быть в устоявшемся формате service worker или в более новом, предпочтительном формате модулей. Теперь точка входа обязательна и может быть указана либо через main поле, либо передать напрямую в командной строке, например, wrangler dev index.js. Это поле заменяет устаревшее build.upload.main поле (которое применялось только к Workers в формате модулей).

• rules: array, необязательно

  rules поле представляет собой массив сопоставлений между типами модулей и шаблонами файлов. Оно указывает Wrangler интерпретировать определённые файлы иначе, чем JavaScript. Например, это полезно для чтения текстоподобного содержимого как текстовых файлов или скомпилированного WASM как готового к созданию экземпляра и выполнению. Эти правила можно применять к Workers как в устоявшемся формате service worker, так и в более новом формате модулей. Это поле заменяет устаревшее build.upload.rules поле (которое применялось только к Workers в формате модулей).

Несколько полей конфигурации, которые ранее были обязательными, теперь в определенных ситуациях являются необязательными. Они могут либо определяться автоматически, либо добавляться в качестве оптимизации. Начиная с Wrangler v2 ни одно поле больше не является обязательным, и вы можете постепенно добавлять конфигурацию по мере необходимости.

• name: string

  name поле конфигурации больше не обязательно для wrangler dev, либо любой из wrangler kv:* команды. Кроме того, это можно передать как аргумент командной строки в виде --name <name>. Это по-прежнему требуется для wrangler deploy.

• account_id: string

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

  По прежнему можно настроить account_id в файле Wrangler, либо в виде переменной окружения CLOUDFLARE_ACCOUNT_ID. Это ускоряет запуск и пропускает список вариантов выбора, если у вас несколько ID. Флаг CLOUDFLARE_API_TOKEN переменная окружения также полезна в ситуациях, когда невозможен интерактивный вход. Подробнее см. Запуск в CI/CD.

• workers_dev boolean, по умолчанию: true когда маршруты отсутствуют

  workers_dev поле используется, чтобы указать, что Worker должен быть опубликован в *.workers.dev поддомен. Например, для Worker с именем my-worker и ранее настроенный *.workers.dev поддомен username, Worker будет опубликован в my-worker.username.workers.dev.com. Это поле необязательное, по умолчанию используется true когда route или routes не настроены. Когда routes заданы, по умолчанию используется false. Если вы не хотите ни публиковать его в *.workers.dev поддомен, ни какие-либо маршруты, задайте workers_dev к false. Это полезно, когда вы публикуете Worker как самостоятельный сервис, доступ к которому возможен только из другого Worker с помощью (services).

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

• zone_id: string, устарело

  zone_id поле устарело и будет удалено в одном из будущих релизов. Теперь оно определяется на основе route/routes, и, при необходимости, из dev.host при использовании wrangler dev. Это также упрощает развёртывание одного Worker на нескольких доменах.

• build.upload: object, устарело

  build.upload поле устарело и будет удалено в одном из будущих релизов. Его использование приводит к предупреждению с рекомендациями по изменению файла конфигурации, чтобы устранить эти предупреждения.

  • build.upload.main/build.upload.dir заменяются на main поля и применимы как к Workers в формате service worker, так и к Workers в формате modules.
  • build.upload.rules заменяется rules поле и применимо как к Workers в формате service worker, так и в формате модулей.
  • build.upload.format больше не указывается и автоматически определяется wrangler.

Несколько полей конфигурации устарели и больше не будут работать как ожидается. Рекомендуется прочитать сообщения об ошибках и следовать инструкциям по переходу на новую конфигурацию.

• site.entry-point: string, устарело

  site.entry-point конфигурация использовалась для указания точки входа для Workers с [site] конфигурацию. Она заменена параметром верхнего уровня main поле.

• type: rust | javascript | webpack, устарело

  type конфигурация использовалась для указания типа Worker. С тех пор она стала избыточной и теперь определяется автоматически по способу использования. Если вы использовали type = "webpack" (и необязательный webpack_config поле), вам следует ознакомиться с руководство по миграции с webpack чтобы изменить проект и вместо этого использовать собственную сборку.

Начиная с Wrangler v2 следующие команды считаются устаревшими.

wrangler build команда больше не используется для сборки Worker.

Аналогичной функциональности можно добиться wrangler publish --dry-run --outdir=path/to/build.

wrangler config команда больше не используется для аутентификации через API-токен.

Используйте wrangler login / wrangler logout для управления аутентификацией OAuth либо передайте токен API через CLOUDFLARE_API_TOKEN переменную окружения.

wrangler preview команда больше не используется для создания временного экземпляра Worker для предпросмотра.

Попробуйте использовать wrangler dev чтобы опробовать worker в процессе разработки.

wrangler subdomain команда больше не используется для создания workers.dev поддомен.

Создайте workers.dev поддомен в Workers & Pages > выберите Worker > Your subdomain > Изменение.

wrangler route команда больше не используется для настройки маршрута Worker.

Маршруты задаются в конфигурационный файл Wrangler.

• Маршруты, заданные в дашборде Cloudflare, не будут добавлены вместе с маршрутами, заданными в Wrangler. Маршруты, заданные в Wrangler, являются route или routes ключ в вашем wrangler.toml. Если заданы оба варианта, используются только маршруты, определённые в wrangler.toml будет действителен. Чтобы управлять маршрутами только через панель управления Cloudflare, удалите все route и routes ключи из и добавьте workers_dev = false в файл Wrangler.

• Wrangler больше не будет использовать index.js в каталоге, где wrangler dev вызывается как точка входа в Worker. Используйте main поле конфигурации, либо явно передать его как аргумент командной строки, например: wrangler dev index.js.

• Wrangler больше не будет считать голые спецификаторы (bare specifiers) именами файлов, если они не представлены в виде пути. Например, в такой папке:

  project
  ├── index.js
  └── some-dependency.js

  где содержимое index.js следующий:

  import SomeDependency from "some-dependency.js";
  
  addEventListener("fetch", (event) => {
    // ...
  });

  Wrangler v1 определял import SomeDependency from "some-dependency.js"; в файл some-dependency.js. Это также будет работать в Wrangler v2, но при этом будет выводиться предупреждение об устаревании. В будущем это приведёт к ошибке. Вместо этого перепишите импорт так, чтобы он явно указывал на относительный путь, например:

  - import SomeDependency from "some-dependency.js";
  + import SomeDependency from "./some-dependency.js";