Kostenbasislinie in Ihrem Projekt verwenden

1. Einführung

Baseline ist eine Initiative, die für eine klarere Kommunikation darüber sorgt, welche Webfunktionen heute interoperabel und sicher zu verwenden sind. Dank der Fortschritte bei den Baseline-Tools können Sie Baseline jetzt direkt in Ihren Projekten als Browserslist-Abfrage verwenden. So kann Ihre Toolchain die Ausgabe von Code basierend auf dem von Ihnen ausgewählten Baseline-Ziel ändern.

In diesem Codelab erfahren Sie, wie Sie Baseline in einem Beispielprojekt verwenden und so konfigurieren, dass ein bestimmtes Baseline-Ziel ausgewählt wird. Sie können auch beobachten, wie sich die Ausgabe der Projekt-Toolchain je nach ausgewähltem Baseline-Ziel ändert.

2. Demo auf dem lokalen Computer einrichten

Rufen Sie zuerst Ihre bevorzugte Terminalanwendung auf, klonen Sie das Demorepository und wechseln Sie dann in das Projektverzeichnis:

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

Zu diesem Zeitpunkt ist Baseline bereits in die Demo integriert. Sie sollten jedoch einen Commit auschecken, der Ihnen einen Neustart ermöglicht:

git checkout d3793f25

Nachdem das Repository geklont wurde, kann die Demo gestartet werden. In diesem Projekt wird nvm zur Verwaltung der Node-Versionsverwaltung verwendet. Wenn Sie eine relativ aktuelle Version von Node global installiert haben, müssen Sie diesen Schritt wahrscheinlich nicht ausführen. Wenn Sie jedoch nvm verwenden, führen Sie die folgenden Befehle aus:

nvm install
nvm use

Installieren Sie von hier aus die Pakete des Projekts:

npm install

Wenn Sie die Demo sehen möchten, führen Sie den folgenden Befehl aus:

npm start

Rufen Sie dann http://localhost:8080 auf. Die Demo selbst ist eine Liste von Karten, die über ein Formularfeld oben auf der Seite gefiltert werden kann. Die App selbst verwendet eine Mischung aus Funktionen, die einen Baseline-Schwellenwert erreicht haben.

Wenn Sie mit der Demo fertig sind, können Sie sie jederzeit beenden, indem Sie im Terminal Strg + C drücken.

3. So integrieren Sie Baseline in das Projekt

In dieser Demo wird zu Beginn keine Browserslist-Konfiguration angegeben. Browserslist ist eine kompakte Abfragesyntax, die Toolchains angibt, welche Mindestbrowserversionen unterstützt werden müssen. Wenn Sie beispielsweise eine Abfrage mit last 3 years verwenden, wird ein breites Spektrum an Zielvorhaben angegeben. In dieser Demo geben wir eine Browserslist-Abfrage an, die mit den Baseline-Zielen übereinstimmt, die Sie in Ihrer Toolchain verwenden können. Basiszielvorhaben können eines der folgenden sein:

  • Dynamische Ziele, die im Laufe der Zeit aktualisiert werden, wenn neue Browser veröffentlicht werden:
    • Baseline Newly available (Neu verfügbare Baseline): Hier werden interoperable Funktionen berücksichtigt, die in den wichtigsten Browsern jederzeit ab heute bis vor 30 Monaten implementiert wurden.
    • Baseline Widely available (Weitgehend verfügbar) umfasst interoperable Funktionen, die vor 30 Monaten oder länger in den wichtigsten Browsern implementiert wurden.
  • Feste Ziele, die Browserversionen zu einem bestimmten Zeitpunkt darstellen. Sie werden als Jahre von 2016 bis zum aktuellen Jahr angegeben.

Zuerst wählen wir das Ziel „Moving Baseline Widely available“ für das Projekt aus. Öffnen Sie dazu package.json und fügen Sie Folgendes hinzu:

"browserslist": "baseline widely available"

4. Änderungen in der Codeausgabe beobachten, indem Sie verschiedene Baseline-Ziele auswählen

Sie haben gerade „Baseline Widely available“ als Ziel für das Demoprojekt ausgewählt. Als Nächstes müssen Sie das Projekt erstellen:

npm run build

Es gibt viele zusätzliche Ausgaben, da die Option debug für @babel/preset-env im babel.config.js des Projekts als true angegeben ist. Sehen Sie sich zuerst die Größe von CSS und JavaScript in den Bundler-Statistiken an:

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]

Das JavaScript-Bundle ist 208 KiB groß und das CSS 3, 64 KiB. In diesem Projekt werden core-js für JavaScript-Polyfills und autoprefixer verwendet, um anbieterspezifische Präfixe für CSS-Eigenschaften anzuwenden, die noch nicht vollständig interoperabel sind. Sowohl core-js als auch autoprefixer werden von der ausgewählten Baseline-Browserslist-Abfrage beeinflusst.

Achten Sie in der Ausgabe auch darauf, wie Ihre Browserslist-Abfrage für „Baseline Widely available“ in eine Browserslist-Abfrage übersetzt wird. In Ihrem Projekt sieht das in etwa so aus:

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

Beachten Sie die von core-js eingefügten Polyfills in der Build-Ausgabe:

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

Diese Ausgabe kann sich ändern, wenn Sie Ihr Baseline-Zielvorhaben ändern. Angenommen, Ihre Anwendung muss aufgrund eines strengeren SLA eine viel ältere Gruppe von Browsern unterstützen. Wenn das bei Ihnen der Fall wäre, würden Sie wahrscheinlich ein konservativeres Ziel auswählen. Ändern Sie in der Datei package.json die Browserslist-Konfiguration so, dass sie Folgendes widerspiegelt:

"browserslist": "baseline 2016"

Damit wird „Baseline 2016“ als Ziel ausgewählt. Die Angabe wird in eine Browserslist-Abfrage übersetzt. Nachdem Sie den Build noch einmal ausgeführt haben, können Sie die Unterschiede in der Toolchain-Ausgabe sehen:

npm run build

Sehen Sie sich zuerst die Änderung der Dateigröße für das JavaScript und CSS des Projekts in den Bundler-Statistiken an:

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]

Das JavaScript-Bundle ist um fast 30 KiB größer geworden. Das CSS des Projekts ist nur geringfügig größer, da autoprefixer basierend auf dem Baseline-Ziel von 2016 weitere Anbieterpräfixe hinzugefügt hat. Beachten Sie auch die Änderung in der Browserslist-Abfrage:

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

Im Vergleich zum Ziel „Weit verbreitet“ sind diese Browserversionen viel älter. Die Edge-Version, die in diesem Fall als Ziel verwendet wird, ist sogar eine Vor-Chromium-Version.

Auch die von core-js eingefügten Polyfills ändern sich. Das ist deutlich mehr als bei Auswahl von „Baseline Widely available“ als Ziel:

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

Die Baseline kann einen erheblichen Einfluss darauf haben, wie Ihre Anwendung durch die Toolchain Ihres Projekts transformiert wird. Die Anwendung in diesem Beispiel ist sehr einfach und enthält weder in React noch in der Anwendung selbst viele innovative Entwicklerfunktionen. Bei wesentlich komplexeren Anwendungen können Sie mit ganz anderen Ergebnissen rechnen, möglicherweise sogar mit mehr Polyfills, Transformationen und anderen Quellen für zusätzlichen Code, um dem von Ihnen ausgewählten Baseline-Ziel zu entsprechen.

5. Targeting auf Downstream-Browser

Die Kernbrowser, auf die Baseline abzielt, sind:

  • Chrome
  • Chrome für Android
  • Firefox
  • Firefox für Android
  • Edge
  • Safari unter macOS
  • Safari unter iOS

Sie können jedoch Targeting auf sogenannte „Downstream-Browser“ festlegen. Die Engines dieser Browser basieren auf einem Browser aus der Kernbrowsergruppe, meistens Chromium. Dazu gehören Browser wie Opera und Samsung Internet. Sie können diese Browser zusätzlich zu den Browsern in der Core-Browsergruppe anvisieren, indem Sie einer gültigen Baseline-Browserslist-Abfrage with downstream hinzufügen:

"browserslist": "baseline widely available with downstream"

Dadurch wird das Targeting auf Downstream-Browser gemäß dem Ziel „Baseline Widely available“ (Weit verbreitete Baseline) festgelegt. So sehen Sie, wie dies in eine Browserslist-Abfrage aufgelöst wird:

npm start

Beachten Sie dann die Änderung in der Browserslist-Abfrage:

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

Sie können auch ein Targeting auf Downstream-Browser nach Jahr festlegen. Beispiel:

"browserslist": "baseline 2016 with downstream"

Mit dieser Konfiguration ändert sich Ihre Browserslist-Abfrage entsprechend:

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

6. Linter und andere Tools

Die in Browserslist integrierten Baseline-Abfragen sind praktisch für Tools wie Bundler und andere Teile Ihrer Toolchain. Es gibt aber auch andere Tools, z. B. Linter, die Baseline-Ziele als Teil ihrer Konfiguration übernommen haben.

Ein gutes Beispiel für die Linter-Unterstützung für Baseline ist ESLint. Im Rahmen des CSS-Lintings wird dort eine use-baseline-Regel mit @eslint/css bereitgestellt, mit der Sie entweder auf „Baseline Newly“, „Baseline Widely available“ oder „Baseline years“ abzielen können. Es gibt auch eine ähnliche Regel im Community-Paket @html-eslint/eslint-plugin, mit der Sie dasselbe für HTML-Funktionen in Ihrer eslint.config.js-Datei tun können:

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

Bei dieser Konfiguration sind einige Dinge zu beachten:

  1. Sowohl das HTML- als auch das CSS-Linting-Paket verwenden eine use-baseline-Regel, die mit der Konfigurationsoption available: "widely" auf „Widely available“ (Weitgehend verfügbar) festgelegt ist.
  2. Für beide Linting-Pakete ist die Protokollebene für Linter-Verstöße auf "warn" festgelegt. Dieser Wert kann auf "error" gesetzt werden, um mit einem Fehlercode abzubrechen und zu verhindern, dass ein Build ausgeführt wird.

Möglicherweise haben Sie die Linter-Ausgabe bereits beim Ausführen von npm run build gesehen. Wenn Sie die Linter-Ausgabe allein sehen möchten, können Sie Folgendes ausführen:

npm run lint

In der Ausgabe werden mehrere Warnungen im CSS des Projekts hervorgehoben:

/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. Zusammenfassung

Die Verwendung der von Browserslist bereitgestellten Baseline-Abfragen in Ihrem Projekt erfordert zwar ein gewisses Verständnis der zugrunde liegenden Build-Tools und von Browserslist selbst, aber das Einfügen in ein Projekt ist einfach. Der Hauptvorteil ist, dass Sie sich nicht mehr um die von Ihnen unterstützten Browser in Bezug auf Versionsnummern kümmern müssen, sondern ein Baseline-Ziel verwenden können, das die Hauptarbeit für Sie erledigt.

Außerdem gibt es eine Version dieser Demo, die auf Rollup ausgeführt wird. Sie können dieser Codelab-Anleitung weitgehend auch mit dieser Demo folgen.

Die Unterstützung von Baselines wird auch in anderen Bündelungstools eingeführt. Vite beispielsweise, das Rollup im Hintergrund verwendet, richtet sich seit Version 7 standardmäßig an Baseline-Browser.

Ganz gleich, wie Sie vorgehen, wenn Sie Baseline-Abfragen, die in Browserslist verfügbar sind, in Ihr Projekt einführen und ein Baseline-Ziel auswählen, das für Sie geeignet ist, können Sie Browser auf einfachere und zuverlässigere Weise ansprechen.