Como usar o Baseline no seu projeto

1. Introdução

O Baseline é uma iniciativa que oferece mensagens mais claras sobre quais recursos da Web são interoperáveis e seguros para uso hoje. Graças aos avanços nas ferramentas do Baseline, agora é possível usá-lo diretamente nos projetos como uma consulta do Browserslist para que o seu conjunto de ferramentas possa mudar a saída do código com base no valor do Baseline escolhido.

Neste codelab, você vai aprender a usar o Baseline em um projeto de exemplo e a configurá-lo para selecionar um valor específico. Você também vai observar como a saída do conjunto de ferramentas do projeto muda dependendo do valor selecionado.

2. Configurar a demonstração na máquina local

Primeiro, acesse o aplicativo de terminal de sua preferência, clone o repositório de demonstração e insira o diretório do projeto:

git clone git@github.com:GoogleChromeLabs/baseline-demos.git
cd baseline-demos/tooling/webpack

Neste ponto, a demonstração já terá o Baseline integrado, mas você vai querer fazer check out de um commit que comece do zero:

git checkout d3793f25

Com o repositório clonado, a demonstração pode ser iniciada. Esse projeto usa o nvm para gerenciar o controle de versões do Node. Se você tiver uma versão não muito antiga do Node instalada globalmente, essa etapa talvez não seja necessária. No entanto, se você usa o nvm, execute os seguintes comandos:

nvm install
nvm use

Agora, instale os pacotes do projeto:

npm install

Para conferir a demonstração, execute o seguinte comando:

npm start

Em seguida, navegue até http://localhost:8080. A demonstração é uma lista de cards que pode ser filtrada usando um campo de formulário na parte de cima da página. O app usa uma combinação de recursos que atingiram um limiar do Baseline.

Quando terminar a demonstração, acesse o terminal e pressione Ctrl+C para interromper a execução a qualquer momento.

3. Como integrar o Baseline ao projeto

Esta demonstração não especifica uma configuração do Browserslist no início. O Browserslist é uma sintaxe de consulta compacta que informa aos conjuntos de ferramentas quais versões mínimas de navegador precisam ser compatíveis. Por exemplo, usar uma consulta de last 3 years vai especificar uma ampla variedade de valores. Nesta demonstração, vamos especificar uma consulta do Browserslist que se alinha aos valores do Baseline que você pode usar no seu conjunto de ferramentas. Os valores do Baseline podem ser uma das seguintes opções:

  • Valores móveis, que são atualizados com o tempo à medida que novos navegadores são lançados:
    • Baseline recém-disponibilizado, que alinha recursos interoperáveis implementados no conjunto principal de navegadores a qualquer momentodos últimos 30 meses.
    • Baseline amplamente disponível, que inclui recursos interoperáveis implementados no conjunto principal de navegadores há 30 meses ou mais.
  • Valores fixos, que representam versões de navegador em um ponto fixo no tempo. Eles são expressos como anos de 2016 até o ano atual.

Para começar, vamos selecionar o valor móvel do Baseline amplamente disponível para o projeto. Para fazer isso, abra package.json e adicione o seguinte:

"browserslist": "baseline widely available"

4. Observe as mudanças na saída do código selecionando diferentes valores de Baseline

Você acabou de selecionar Baseline amplamente disponível como o valor do projeto de demonstração. Em seguida, crie o projeto:

npm run build

Há muita saída extra porque a opção debug para @babel/preset-env é especificada como true no babel.config.js do projeto. Primeiro, observe o tamanho do CSS e do JavaScript nas estatísticas do empacotador:

assets by status 213 KiB [emitted]
  asset js/home.5f3c5480.js 208 KiB [emitted] [immutable] [minimized] (name: home) 2 related assets
  asset css/home.20db50ef.css 3.64 KiB [emitted] [immutable] (name: home) 1 related asset
  asset index.html 564 bytes [emitted]

O pacote JavaScript tem 208 KiB, e o CSS tem 3,64 KiB. Isso porque o projeto usa core-js para polyfills JavaScript e autoprefixer para aplicar prefixos específicos do fornecedor a propriedades CSS que ainda não são totalmente interoperáveis. Tanto core-js quanto autoprefixer são afetados pela consulta do Baseline ao Browserslist selecionada.

Outra coisa a ser observada na saída é como sua consulta do Browserslist para o Baseline amplamente disponível é traduzida em uma consulta do Browserslist. No seu projeto, isso vai ficar parecido com isto:

Using targets: {
  "chrome": "108",
  "edge": "108",
  "firefox": "108",
  "ios": "16",
  "safari": "16"
}

Observe os polyfills injetados por core-js na saída da build:

The corejs3 polyfill added the following polyfills:
  es.iterator.constructor { "chrome":"108", "edge":"108", "firefox":"108", "ios":"16", "safari":"16" }
  es.iterator.filter { "chrome":"108", "edge":"108", "firefox":"108", "ios":"16", "safari":"16" }
  es.iterator.map { "chrome":"108", "edge":"108", "firefox":"108", "ios":"16", "safari":"16" }

Essa saída pode mudar se você alterar o valor do Baseline. Digamos que seu aplicativo precise oferecer suporte a um conjunto muito mais antigo de navegadores devido a um SLA mais rigoroso. Se esse for o caso, provavelmente você vai selecionar uma meta mais conservadora. No arquivo package.json, mude a configuração do Browserslist para refletir o seguinte:

"browserslist": "baseline 2016"

Isso seleciona "Baseline 2016" como valor e será traduzido para uma consulta do Browserslist. Observe as diferenças na saída do conjunto de ferramentas depois de executar o build novamente:

npm run build

Primeiro, observe a mudança no tamanho dos arquivos JavaScript e CSS do projeto nas estatísticas do empacotador:

assets by status 237 KiB [emitted]
  asset js/home.b228612d.js 232 KiB [emitted] [immutable] [minimized] (name: home) 2 related assets
  asset css/home.0c3e4fd7.css 3.91 KiB [emitted] [immutable] (name: home) 1 related asset
  asset index.html 564 bytes [emitted]

Você vai notar que o pacote JavaScript aumentou de tamanho em quase 30 KiB. O CSS do projeto é apenas um pouco maior, devido ao autoprefixer, que adicionou mais prefixos de fornecedor com base no valor do Baseline de 2016. Observe também a mudança na consulta do Browserslist:

Using targets: {
  "chrome": "53",
  "edge": "14",
  "firefox": "49",
  "ios": "10",
  "safari": "10"
}

Em comparação com o valor do Baseline amplamente disponível, essas versões de navegador são muito, muito anteriores. A versão do Edge segmentada neste caso é pré-Chromium.

Os polyfills injetados por core-js também vão mudar, e consideravelmente mais do que quando o Baseline amplamente disponível foi selecionado como valor:

The corejs3 polyfill added the following polyfills:
  es.array.filter { "edge":"14" }
  es.iterator.constructor { "chrome":"53", "edge":"14", "firefox":"49", "ios":"10", "safari":"10" }
  es.iterator.filter { "chrome":"53", "edge":"14", "firefox":"49", "ios":"10", "safari":"10" }
  es.object.to-string { "edge":"14", "firefox":"49" }
  es.array.includes { "firefox":"49" }
  es.string.includes { "edge":"14" }
  es.array.map { "firefox":"49" }
  es.iterator.map { "chrome":"53", "edge":"14", "firefox":"49", "ios":"10", "safari":"10" }
  es.symbol { "edge":"14", "firefox":"49" }
  es.symbol.description { "chrome":"53", "edge":"14", "firefox":"49", "ios":"10", "safari":"10" }
  es.array.iterator { "chrome":"53", "edge":"14", "firefox":"49" }
  web.dom-collections.iterator { "chrome":"53", "edge":"14", "firefox":"49", "ios":"10", "safari":"10" }
  es.array.push { "chrome":"53", "edge":"14", "firefox":"49", "ios":"10", "safari":"10" }
  es.regexp.to-string { "edge":"14" }
  es.array.from { "edge":"14", "firefox":"49" }
  es.regexp.exec { "chrome":"53", "edge":"14", "firefox":"49", "ios":"10", "safari":"10" }
  es.regexp.test { "edge":"14" }
  es.error.cause { "chrome":"53", "edge":"14", "firefox":"49", "ios":"10", "safari":"10" }

O ponto principal aqui é que o valor do Baseline pode ter um impacto significativo na forma como seu aplicativo é transformado pelo conjunto de ferramentas do projeto. O aplicativo neste exemplo é muito básico, sem muitos recursos de experiência do desenvolvedor de ponta no React ou no próprio aplicativo. Para aplicativos consideravelmente mais complexos, você pode esperar resultados muito diferentes, talvez até mais em termos de polyfills, transformações e outras fontes de código adicional para cumprir o valor do Baseline escolhido.

5. Segmentação de navegadores downstream

Para revisar, o conjunto principal de navegadores que o Baseline segmenta inclui os seguintes navegadores:

  • Chrome
  • Chrome no Android
  • Firefox
  • Firefox no Android
  • Edge
  • Safari no macOS
  • Safari no iOS

No entanto, é possível segmentar o que são conhecidos como "navegadores downstream". Esses navegadores são aqueles cujos mecanismos derivam de um navegador no conjunto principal, geralmente o Chromium. Isso inclui navegadores como Opera, Samsung Internet e outros. É possível segmentar esses navegadores além dos que estão no conjunto principal de navegadores adicionando with downstream a qualquer consulta válida do Baseline ao Browserslist:

"browserslist": "baseline widely available with downstream"

Isso segmenta navegadores downstream de acordo com o valor do Baseline amplamente disponível. Para ver como isso é resolvido em uma consulta do Browserslist, recrie o projeto:

npm start

Em seguida, observe a mudança na consulta do Browserslist:

Using targets: {
  "android": "108",
  "chrome": "108",
  "edge": "108",
  "firefox": "108",
  "ios": "16",
  "opera": "94",
  "opera_mobile": "80",
  "safari": "16",
  "samsung": "21"
}

Também é possível segmentar navegadores downstream por ano. Exemplo:

"browserslist": "baseline 2016 with downstream"

Com essa configuração, sua consulta do Browserslist vai mudar de acordo:

Using targets: {
  "android": "53",
  "chrome": "53",
  "edge": "14",
  "firefox": "49",
  "ios": "10",
  "opera": "40",
  "opera_mobile": "80",
  "safari": "10",
  "samsung": "6.2"
}

6. Linters e outras ferramentas

As consultas do Baseline integradas ao Browserslist são convenientes para ferramentas como empacotadores e outras partes do seu conjunto de ferramentas, mas também há benefícios em outras ferramentas, como linters, que adotaram valores do Baseline como parte da configuração.

Um bom exemplo de suporte do linter para o Baseline inclui o ESLint, que, como parte da inspeção de CSS, fornece uma regra use-baseline usando @eslint/css que permite segmentar o Baseline recém-disponibilizado, o Baseline amplamente disponível ou o Baseline por ano. Há também uma regra semelhante no pacote @html-eslint/eslint-plugin da comunidade que permite fazer o mesmo para recursos HTML no arquivo eslint.config.js:

export default [
  /* Omitted JS linting rules ... */
  // Lint CSS files for Baseline:
  {
    files: ["**/*.css"],
    plugins: {
      css
    },
    language: "css/css",
    rules: {
      "css/no-duplicate-imports": "error",
      // Lint CSS files to make sure they are using
      // only Baseline Widely available features:
      "css/use-baseline": ["warn", {
        available: "widely"
      }]
    },
  },
  // Lint HTML and JSX files for Baseline:
  {
    files: ["**/*.html"],
    ...html.configs["flat/recommended"],
    rules: {
      // Lint HTML files to make sure they are using
      // only Baseline Widely available features:
      "@html-eslint/use-baseline": ["warn", {
        available: "widely"
      }]
    }
  }
];

Há alguns pontos importantes nessa configuração:

  1. Os pacotes de linting HTML e CSS usam uma regra use-baseline, que é definida como amplamente disponível usando a opção de configuração available: "widely".
  2. Para os dois pacotes de lint, o nível de registro das violações do linter é definido como "warn". Ele pode ser definido como "error" para desistir com um código de erro e evitar que um build ocorra.

Talvez você já tenha visto a saída do linter ao executar npm run build, mas para ver a saída do linter por si só, execute o seguinte:

npm run lint

A saída que você vai ver destaca vários avisos no CSS do projeto:

/var/www/baseline-demos/tooling/webpack-browserslist-config-baseline/src/css/normalize.css
  222:3  warning  Property 'outline' is not a widely available baseline feature  css/use-baseline

/var/www/baseline-demos/tooling/webpack-browserslist-config-baseline/src/css/styles.css
  62:3   warning  Property 'outline' is not a widely available baseline feature                                css/use-baseline
  81:23  warning  Value 'subgrid' of property 'grid-template-rows' is not a widely available baseline feature  css/use-baseline

7. Conclusão

Para usar as consultas do Baseline fornecidas pelo Browserslist no seu projeto, é necessário entender as ferramentas de build e o próprio Browserslist, mas a ação de colocá-las em um projeto é concisa. O principal benefício de usar o recurso é que você não precisa mais pensar nos navegadores compatíveis em termos de números de versão, mas sim em um valor do Baseline que cuide disso para você.

Além disso, há uma versão desta demonstração que é executada no Rollup, e este codelab pode ser seguido usando essa demonstração também.

O suporte ao Baseline também está começando a aparecer em outras ferramentas de empacotamento. O Vite, por exemplo, que usa o Rollup por baixo dos panos, desde a versão 7 passou a usar os navegadores do Baseline amplamente disponível como valor padrão.

De qualquer forma, ao introduzir consultas do Baseline ao Browserslist no seu projeto e selecionar um valor do Baseline que funcione para você, é possível segmentar navegadores de uma maneira mais simples e confiável.