Firefox 147 добавляет сервис-воркеры типа модуля — что теперь должны сделать команды полного стека

Что произошло

• Firefox 147 (стабильная версия, январь 2026) представил поддержку сервис-воркеров в качестве ECMAScript модулей — т.е. вы можете зарегистрировать сервис-воркер с { type: 'module' } и использовать import/export и семантику модулей внутри воркера. (developer.mozilla.org)

Почему это важно (высокое воздействие)

• Современный, повторно используемый код в воркере: вы можете импортировать общие утилитарные модули, применять tree-shake для меньших нагрузок и поддерживать паритет между кодом основного потока и кодом воркера.
• Top-level await, строгая семантика ESM и встроенное разрешение модулей устраняют необходимость в importScripts и хрупких шаблонах конкатенации.
• Проще интегрировать инструменты: сборщики/пакетировщики, которые генерируют ESM-выходы, могут напрямую передавать сервис-воркерам, снижая необходимость в хаках на этапе сборки.
• Безопасность и поддерживаемость: более четкие границы модулей и более легкий аудит графов зависимостей внутри воркеров.

Что команды полного стека должны сделать сейчас — конкретный, приоритетный список

1. Быстрая проверка совместимости

   • Проверьте ваши целевые браузеры и пользовательскую базу (доступность Firefox 147+ в вашей телеметрии). Если значительная доля пользователей использует более старые версии Firefox или другие браузеры, которые могут не обновляться автоматически в вашей среде, запланируйте резервный вариант. (developer.mozilla.org)

2. Обнаружение функций и безопасная регистрация

   • Используйте обнаружение функций и условную регистрацию: попытайтесь navigator.serviceWorker.register('/sw.js', { type: 'module' }), когда это поддерживается, в противном случае вернитесь к классической регистрации. Не принуждайте регистрацию модуля без резервного варианта в публично доступных продуктах.

3. Миграция кода воркера на ESM

   • Замените importScripts(...) на import ... from '...' и преобразуйте код в стиле CommonJS в ESM (или предоставьте совместимые с ESM точки входа).
   • Удалите глобальные побочные эффекты, которые зависели от порядка importScripts; полагайтесь на явные импорты и инициализацию.

4. Изменения в сборочном процессе

   • Настройте пакетировщики для генерации ESM-выходов для сервис-воркеров (сохраняйте операторы импорта или генерируйте .mjs, где это необходимо).
   • Убедитесь, что ваш сервер возвращает правильные MIME-типы (например, text/javascript или application/javascript) для файлов модулей и поддерживает CORS-учетные данные, как требуется для загрузки модулей.
   • Если вы используете хешированные имена файлов или CDN для активов, подтвердите, что воркеры могут импортировать эти URL во время выполнения (или встроить небольшой манифест).

5. Политика безопасности контента (CSP) и заголовки

   • Проверьте CSP: импорты модулей в воркерах загружаются как обычные модули; убедитесь, что правила script-src/worker-src не блокируют эти запросы.
   • Если вы используете параметры регистрации сервис-воркера, которые изменяют поведение загрузки, проверьте правила одного источника/кросс-источника и куки/учетные данные.

6. Библиотеки и инструменты

   • Протестируйте Workbox и другие распространенные библиотеки SW на совместимость с модульным режимом; обновите до версий, которые явно поддерживают type: 'module' (или мигрируйте на ручное управление).
   • Обновите локальные серверы разработки (и CI), чтобы последовательно обслуживать модульные воркеры (следите за настройками по умолчанию серверов разработки, которые внедряют обертки или используют неправильные заголовки CORS).

7. Тесты и развертывание

   • Добавьте end-to-end тесты, которые:
     • регистрируют воркер в модульном режиме,
     • подтверждают, что импорты разрешаются (и top-level await работает, если используется),
     • проверяют поведение оффлайн и жизненный цикл кеша на модульных воркерах.
   • Проведите канарейку для небольшого процента трафика; следите за регистрациями сервис-воркеров, сбоями активации и журналами ошибок.
   • Обеспечьте телеметрию или отлов ошибок (sentry/logging) вокруг ServiceWorkerContainer.register(), чтобы обнаружить резервные варианты для неподдерживаемых клиентов.

Распространенные ошибки, на которые стоит обратить внимание

• Выход пакетировщика несовместим с загрузчиком модулей (IIFE против ESM). Генерируйте ESM точки входа для воркеров.
• Полагание на семантику последовательности importScripts — замените на явные импорты и порядок инициализации.
• Более старые браузеры (или заблокированные корпоративные среды) не могут зарегистрироваться, если вы опустите классический резервный вариант.
• Неправильные MIME/CORS или CSP блокируют импорты модулей и вызывают тихие сбои при регистрации.

Краткий план развертывания (одна страница)

• Неделя 0: Добавьте обнаружение функций + регистрацию с резервным вариантом; проведите тестирование на стадии.
• Неделя 1: Преобразуйте воркер в ESM; обновите MIME/CORS на сервере и в сборке.
• Неделя 2: Добавьте e2e тесты; разверните на канарейке (1–5%).
• Неделя 3: Следите за ошибками/метриками; расширьте развертывание до 25%, затем до 100% после чистой телеметрии.

Итог Поддержка сервис-воркеров типа модуля в Firefox 147 превращает воркеры в первоклассных потребителей ESM. Для команд полного стека это означает более чистое совместное использование кода, более простые сборки и более мощную логику сервис-воркеров — но это требует целенаправленных изменений в сборке, регистрации и развертывании. Начните с обнаружения функций и поэтапной миграции, чтобы избежать сюрпризов в средах, которые все еще используют более старые клиенты. (developer.mozilla.org)

Источник:

Источник

• Source