Módulos ES em service workers

Uma alternativa moderna para importScripts().

Jeff Posnick

Contexto

Os módulos ES têm sido os favoritos dos desenvolvedores há algum tempo. Além de vários outros benefícios, eles oferecem a promessa de um formato de módulo universal, em que o código compartilhado pode ser lançado uma vez e executado em navegadores e em ambientes de execução alternativos, como o Node.js. Embora todos os navegadores modernos ofereçam suporte a módulos ES, nem todos oferecem suporte em todos os lugares em que o código pode ser executado. Especificamente, o suporte à importação de módulos ES dentro de um service worker de um navegador está apenas começando a ser disponibilizado.

Neste artigo, detalhamos o estado atual do suporte ao módulo ES em service workers em navegadores comuns, além de alguns problemas que precisam ser evitados e as práticas recomendadas para enviar código de service worker compatível com versões anteriores.

Casos de uso

O caso de uso ideal para módulos ES dentro de service workers é carregar uma biblioteca moderna ou um código de configuração compartilhado com outros ambientes de execução que oferecem suporte a módulos ES.

A tentativa de compartilhar código dessa maneira antes dos módulos ES implicava o uso de formatos de módulo universais mais antigos, como UMD, que incluem código boilerplate desnecessário e código de escrita que fazia alterações em variáveis globalmente expostas.

Os scripts importados por módulos ES podem acionar o fluxo de atualização do service worker se o conteúdo mudar, correspondendo ao comportamento de importScripts().

Limitações atuais

Somente importações estáticas

Os módulos ES podem ser importados de duas maneiras: estaticamente, usando a sintaxe import ... from '...', ou dinamicamente, usando o método import(). Dentro de um service worker, apenas a sintaxe estática tem suporte no momento.

Essa limitação é análoga a uma restrição semelhante aplicada ao uso de importScripts(). As chamadas dinâmicas para importScripts() não funcionam dentro de um service worker, e todas as chamadas importScripts(), que são inerentemente síncronas, precisam ser concluídas antes que o service worker conclua a fase install. Essa restrição garante que o navegador saiba e armazene em cache implicitamente todo o código JavaScript necessário para a implementação de um service worker durante a instalação.

Com o tempo, essa restrição pode ser suspensa, e as importações dinâmicas de módulos ES podem ser permitidas. Por enquanto, use apenas a sintaxe estática dentro de um service worker.

E os outros workers?

O suporte a módulos ES em workers "dedicados" (aqueles construídos com new Worker('...', {type: 'module'})) é mais generalizado e tem suporte do Chrome e do Edge desde a versão 80, bem como das versões recentes do Safari. As importações de módulo ES estático e dinâmico são compatíveis com workers dedicados.

O Chrome e o Edge têm suporte a módulos ES em workers compartilhados desde a versão 83, mas nenhum outro navegador oferece suporte no momento.

Não há suporte para a importação de mapas

A importação de mapas permite que os ambientes de execução reescrevam os especificadores de módulo para, por exemplo, anexar o URL de uma CDN preferencial de onde os módulos ES podem ser carregados.

Embora o Chrome e o Edge versão 89 e mais recentes sejam compatíveis com mapas de importação, eles não podem ser usados com service workers.

Suporte ao navegador

Os módulos ES em service workers são compatíveis com o Chrome e o Edge a partir da versão 91.

O Safari adicionou suporte à versão 122 de visualização da tecnologia, e os desenvolvedores devem esperar que essa funcionalidade seja lançada na versão estável do Safari no futuro.

Exemplo de código

Esse é um exemplo básico de como usar um módulo ES compartilhado no contexto window de um app da Web e registrar um service worker que usa o mesmo módulo ES:

// Inside config.js:
export const cacheName = 'my-cache';

// Inside your web app:
<script type="module">
  import {cacheName} from './config.js';
  // Do something with cacheName.

  await navigator.serviceWorker.register('es-module-sw.js', {
    type: 'module',
  });
</script>

// Inside es-module-sw.js:
import {cacheName} from './config.js';

self.addEventListener('install', (event) => {
  event.waitUntil((async () => {
    const cache = await caches.open(cacheName);
    // ...
  })());
});

Compatibilidade com versões anteriores

O exemplo acima funcionaria bem se todos os navegadores fossem compatíveis com módulos ES em service workers, mas, no momento, esse não é o caso.

Para acomodar navegadores que não têm suporte integrado, execute o script do service worker usando um bundler compatível com módulo ES para criar um service worker que inclua todo o código do módulo inline e funcione em navegadores mais antigos. Como alternativa, se os módulos que você está tentando importar já estiverem disponíveis em pacotes nos formatos IIFE ou UMD, será possível importá-los usando importScripts().

Quando você tiver duas versões do service worker disponíveis, uma que use módulos ES e outra que não use, será necessário detectar o que o navegador atual oferece suporte e registrar o script do service worker correspondente. As práticas recomendadas para detectar suporte estão em fluxo, mas você pode seguir a discussão neste problema do GitHub para ver recomendações.

_Foto de Vlado Paunovic em Unsplash_