Cómo usar Baseline en tu proyecto

1. Introducción

Baseline es una iniciativa que proporciona mensajes más claros sobre qué funciones web son interoperables y seguras para usar hoy. Gracias a los avances en las herramientas de Baseline, ahora puedes usar Baseline directamente en tus proyectos como una consulta de Browserslist para que tu cadena de herramientas pueda cambiar el resultado del código según el destino de Baseline que elijas.

En este codelab, aprenderás a usar Baseline en un proyecto de muestra y a configurarlo para seleccionar un destino de Baseline específico. También observarás cómo cambia el resultado de la cadena de herramientas del proyecto según el destino de Baseline que seleccionaste.

2. Configura la demostración en tu máquina local

Primero, ve a la aplicación de terminal que prefieras, clona el repositorio de demostración y, luego, ingresa al directorio del proyecto:

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

En este punto, la demostración ya tendrá Baseline integrado, pero te recomendamos que consultes una confirmación que te permita comenzar desde cero:

git checkout d3793f25

Con el repositorio clonado, ahora se puede iniciar la demostración. Este proyecto usa nvm para administrar el control de versiones de Node. Si tienes instalada de forma global una versión razonablemente reciente de Node, es probable que no necesites completar este paso, pero, si usas nvm, ejecuta los siguientes comandos:

nvm install
nvm use

Desde aquí, instala los paquetes del proyecto:

npm install

Si quieres ver la demostración, ejecuta el siguiente comando:

npm start

Luego, navega a http://localhost:8080. La demostración en sí es una lista de tarjetas que se pueden filtrar con un campo de formulario en la parte superior de la página. La app usa una combinación de funciones que alcanzaron un umbral de Baseline.

Cuando termines con la demostración, ve a la terminal y presiona Ctrl + C para detener la ejecución en cualquier momento.

3. Cómo integrar Baseline en el proyecto

Esta demostración no especifica una configuración de Browserslist al principio. Browserslist es una sintaxis de consulta compacta que le indica a las cadenas de herramientas qué versiones mínimas del navegador se deben admitir. Por ejemplo, usar una consulta de last 3 years especificará una amplia variedad de destinos. En esta demostración, especificaremos una consulta de Browserslist que se alinee con los destinos de Baseline que puedes usar en tu cadena de herramientas. Los destinos de Baseline pueden ser uno de los siguientes:

  • Destinos móviles, que se actualizan con el tiempo a medida que se lanzan navegadores nuevos:
    • Baseline Newly available, que alinea las funciones interoperables implementadas en el conjunto de navegadores principales en cualquier momento desde el presente hasta hace 30 meses.
    • Baseline Widely available, que incluye funciones interoperables que se implementaron en el conjunto de navegadores principales hace 30 meses o más.
  • Destinos fijos, que representan versiones del navegador en un punto fijo en el tiempo. Se expresan como años desde 2016 hasta el año actual.

Para comenzar, seleccionaremos el destino móvil Baseline Widely available para el proyecto. Para ello, abre package.json y agrega lo siguiente:

"browserslist": "baseline widely available"

4. Observa los cambios en el resultado del código seleccionando diferentes destinos de Baseline

Acabas de seleccionar Baseline Widely available como destino para el proyecto de demostración. A continuación, deberás compilar el proyecto:

npm run build

Hay muchos resultados adicionales porque la opción debug para @babel/preset-env se especifica como true en el archivo babel.config.js del proyecto. Primero, observa el tamaño de CSS y JavaScript en las estadísticas del agrupador:

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]

Ten en cuenta que el paquete de JavaScript es de 208 KiB y el CSS es de 3.64 KiB. Esto se debe a que este proyecto usa core-js para los polyfills de JavaScript y autoprefixer para aplicar prefijos específicos del proveedor para las propiedades de CSS que aún no son completamente interoperables. Tanto core-js como autoprefixer se ven afectados por la consulta de Browserslist de Baseline seleccionada.

Otra cosa en el resultado a la que debes prestar atención es cómo se traduce tu consulta de Browserslist para Baseline Widely available en una consulta de Browserslist. En tu proyecto, se verá de forma similar a lo siguiente:

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

Observa los polyfills insertados por core-js en el resultado de la compilación:

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" }

Este resultado puede cambiar si cambias tu destino de Baseline. Supongamos que tu aplicación debe admitir un conjunto de navegadores mucho más antiguo debido a un ANS más estricto. Si ese fuera el caso, es probable que selecciones un destino más conservador. En tu archivo package.json, cambia la configuración de Browserslist para reflejar lo siguiente:

"browserslist": "baseline 2016"

Esto selecciona Baseline 2016 como destino y se traducirá a una consulta de Browserslist. Puedes observar las diferencias en el resultado de la cadena de herramientas después de volver a ejecutar la compilación:

npm run build

Primero, observa el cambio en el tamaño del archivo para JavaScript y CSS del proyecto en las estadísticas del agrupador:

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]

Notarás que el paquete de JavaScript aumentó de tamaño en casi 30 KiB. El CSS del proyecto es solo un poco más grande, debido a que autoprefixer agrega más prefijos de proveedor según el destino de Baseline 2016. También observa el cambio en la consulta de Browserslist:

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

En comparación con el destino Baseline Widely available, estas versiones del navegador son mucho, mucho anteriores, lo suficiente como para que la versión de Edge que se segmenta en este caso sea anterior a Chromium.

Los polyfills insertados por core-js también cambiarán, lo que es considerablemente más que cuando se seleccionó Baseline Widely available como destino:

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" }

La conclusión aquí es que tu destino de Baseline puede tener un impacto significativo en la forma en que tu cadena de herramientas del proyecto transforma tu aplicación. La aplicación de este ejemplo es muy básica y no tiene muchas funciones de experiencia del desarrollador de vanguardia en React ni en la aplicación. Para aplicaciones mucho más complejas, puedes esperar resultados muy diferentes, posiblemente incluso más en cuanto a polyfills, transformaciones y otras fuentes de código adicional agregados para cumplir con el destino de Baseline que elijas.

5. Segmentación de navegadores descendentes

Para revisar, el conjunto de navegadores principales que segmenta Baseline incluye los siguientes navegadores:

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

Sin embargo, puedes segmentar lo que se conoce como "navegadores descendentes". Estos navegadores son aquellos cuyos motores se derivan de un navegador en el conjunto de navegadores principales, con mayor frecuencia Chromium. Entre ellos, se incluyen navegadores como Opera, Samsung Internet y otros. Puedes segmentar estos navegadores además de los del conjunto de navegadores principales agregando with downstream a cualquier consulta de Browserslist de Baseline válida:

"browserslist": "baseline widely available with downstream"

Esto segmenta los navegadores descendentes de acuerdo con el destino Baseline Widely available. Para ver cómo se resuelve en una consulta de Browserslist, vuelve a compilar el proyecto:

npm start

Luego, observa el cambio en la consulta de Browserslist:

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

También puedes segmentar navegadores descendentes por año. Por ejemplo:

"browserslist": "baseline 2016 with downstream"

Con esta configuración, tu consulta de Browserslist cambiará en consecuencia:

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

6. Linters y otras herramientas

Las consultas de Baseline integradas en Browserslist son convenientes para herramientas como los agrupadores y otras partes de tu cadena de herramientas, pero también son valiosas otras herramientas, como los linters, que adoptaron destinos de Baseline como parte de su configuración.

Un buen ejemplo de compatibilidad con linters para Baseline incluye ESLint, que, como parte de su linting de CSS, proporciona una use-baseline regla con @eslint/css que te permite segmentar Baseline Newly, Baseline Widely available o años de Baseline. También hay una regla similar en el paquete @html-eslint/eslint-plugin de la comunidad que te permite hacer lo mismo para las funciones HTML en tu archivo 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"
      }]
    }
  }
];

Hay algunas cosas que debes tener en cuenta en esta configuración:

  1. Los paquetes de linting de HTML y CSS usan una regla use-baseline, y se establece en Widely available con la opción de configuración available: "widely".
  2. Para ambos paquetes de linting, el nivel de registro de las infracciones del linter se establece en "warn". Se puede establecer en "error" para descartar con un código de error y evitar que se produzca una compilación.

Es posible que hayas visto el resultado del linter cuando ejecutaste npm run build antes, pero, para ver el resultado del linter por sí solo, puedes ejecutar lo siguiente:

npm run lint

En el resultado que verás, se destacan varias advertencias en el CSS del proyecto:

/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. Conclusión

El uso de las consultas de Baseline que proporciona Browserslist en tu proyecto requiere cierta comprensión de las herramientas de compilación subyacentes y de Browserslist, pero el acto de colocarlas en un proyecto es conciso. El principal beneficio de usarlo es que ya no necesitas pensar en los navegadores que admites en términos de números de versión, sino en un destino de Baseline que hace el trabajo pesado por ti.

Además, hay una versión de esta demostración que se ejecuta en Rollup, y este codelab se puede seguir en gran medida con esa demostración.

La compatibilidad con Baseline también comienza a aparecer en otras herramientas de agrupación. Vite, por ejemplo, que usa Rollup en segundo plano, ahora segmenta los navegadores Baseline Widely available de forma predeterminada desde la versión 7.

Sin importar cómo decidas hacerlo, si introduces consultas de Baseline disponibles en Browserslist en tu proyecto y seleccionas un destino de Baseline que funcione para ti, puedes segmentar navegadores de una manera más simple y confiable.