Ta strona została przetłumaczona przez Cloud Translation API.

Jak korzystać z Baseline w projekcie

1. Wprowadzenie

Baseline to inicjatywa, która ma na celu przekazywanie bardziej przejrzystych informacji o tym, które funkcje internetowe są interoperacyjne i bezpieczne w użyciu. Dzięki postępom w narzędziach Baseline możesz teraz używać Baseline bezpośrednio w swoich projektach jako zapytania Browserslist. Dzięki temu Twój łańcuch narzędzi może zmieniać dane wyjściowe kodu na podstawie wybranego przez Ciebie celu Baseline.

Z tego ćwiczenia w Codelabs dowiesz się, jak używać Baseline w przykładowym projekcie i jak skonfigurować go tak, aby wybierał określony cel Baseline. Zobaczysz też, jak zmieniają się wyniki łańcucha narzędzi projektu w zależności od wybranego celu bazowego.

2. Konfigurowanie wersji demonstracyjnej na komputerze lokalnym

Najpierw otwórz wybraną aplikację terminala, sklonuj repozytorium demonstracyjne, a następnie przejdź do katalogu projektu:

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

W tym momencie wersja demonstracyjna będzie już zawierać Baseline, ale warto sprawdzić commit, który zaczyna od zera:

git checkout 94f12e34

Po sklonowaniu repozytorium można uruchomić wersję demonstracyjną. Ten projekt używa nvm do zarządzania wersjami Node. Jeśli masz zainstalowaną globalnie dość nową wersję Node, prawdopodobnie nie musisz wykonywać tego kroku. Jeśli jednak używasz nvm, uruchom te polecenia:

nvm install
nvm use

Zainstaluj pakiety projektu:

npm install

Jeśli chcesz zobaczyć wersję demonstracyjną, uruchom to polecenie:

npm start

Następnie otwórz adres http://localhost:8080. Demo to lista kart, którą można filtrować za pomocą pola formularza u góry strony. Aplikacja korzysta z różnych funkcji, które osiągnęły próg wartości bazowej.

Gdy skończysz prezentację, w dowolnym momencie możesz ją zatrzymać, naciskając Ctrl+C w terminalu.

3. Jak zintegrować Baseline z projektem

W tej wersji demonstracyjnej na początku nie określono konfiguracji Browserslist. Browserslist to kompaktowa składnia zapytań, która informuje łańcuchy narzędzi, jakie minimalne wersje przeglądarek muszą być obsługiwane. Na przykład użycie zapytania last 3 years określi szeroki zakres miejsc docelowych. W tym przykładzie użyjemy pakietu npm o nazwie browserslist-config-baseline, aby określić zapytanie Browserslist zgodne z celami Baseline, których możesz używać w swoim łańcuchu narzędzi.

Aby rozpocząć, zainstaluj browserslist-config-baseline w ten sposób:

npm install browserslist-config-baseline --save-dev

Po zainstalowaniu tego pakietu możesz określić w projekcie zapytanie extendsBrowserslist, które zostanie przekształcone w listę przeglądarek podstawowych. Te wartości docelowe mogą być:

Zmienne wartości docelowe, które są aktualizowane z czasem w miarę pojawiania się nowych przeglądarek:
- Baseline Newly available, która obejmuje funkcje interoperacyjne zaimplementowane w podstawowym zestawie przeglądarek w dowolnym momencie od teraz do 30 miesięcy temu.
- Baseline Widely available, która obejmuje funkcje interoperacyjne wdrożone w podstawowym zestawie przeglądarek co najmniej 30 miesięcy temu.
Stałe miejsca docelowe, które reprezentują wersje przeglądarek w określonym momencie. Są one wyrażone w latach od 2016 r. do bieżącego roku.

Na początek użyjemy ikony browserslist-config-baseline, aby wybrać ruchomy cel „Dostępność powszechna” dla projektu. Aby to zrobić, otwórz package.json i dodaj te elementy:

"browserslist": "extends browserslist-config-baseline"

4. Obserwuj zmiany w wynikach kodu, wybierając różne wartości docelowe linii bazowej.

Jako cel projektu demonstracyjnego wybrano opcję „Baseline Widely available”. Następnie skompiluj projekt:

npm run build

Jest dużo dodatkowych danych wyjściowych, ponieważ opcja debug dla @babel/preset-env jest określona jako true w pliku babel.config.js projektu. Najpierw sprawdź rozmiar CSS i JavaScript w statystykach narzędzia do łączenia plików:

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]

Zwróć uwagę, że pakiet JavaScript ma rozmiar 208 KiB, a plik CSS – 3,64 KiB. Ten projekt używa core-js do wypełniania luk w obsłudze JavaScriptu i autoprefixer do stosowania prefiksów specyficznych dla dostawców w przypadku właściwości CSS, które nie są jeszcze w pełni interoperacyjne. Na wartości core-js i autoprefixer wpływa wartość browserslist-config-baseline.

Kolejną rzeczą, na którą warto zwrócić uwagę w danych wyjściowych, jest to, jak zapytanie Browserslist dotyczące funkcji Baseline Widely available jest tłumaczone na zapytanie Browserslist. W projekcie będzie to wyglądać mniej więcej tak:

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

Zwróć uwagę na polyfille wstrzyknięte przez core-js w danych wyjściowych kompilacji:

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

Ten wynik może się zmienić, jeśli zmienisz docelową wartość bazową. Załóżmy, że Twoja aplikacja musi obsługiwać starsze przeglądarki ze względu na bardziej rygorystyczną umowę SLA. W takim przypadku prawdopodobnie wybierzesz bardziej konserwatywny cel. W pliku package.json zmień konfigurację Browserslist, aby odzwierciedlała te ustawienia:

"browserslist": "extends browserslist-config-baseline/2016"

Wybiera to jako cel Baseline 2016 i zostanie przetłumaczone na zapytanie Browerslist. Po ponownym uruchomieniu kompilacji możesz zauważyć różnice w danych wyjściowych łańcucha narzędzi:

npm run build

Najpierw zwróć uwagę na zmianę rozmiaru plików JavaScript i CSS projektu w statystykach narzędzia do łączenia:

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]

Zauważysz, że rozmiar pakietu JavaScript zwiększył się o prawie 30 KiB. Arkusz CSS projektu jest tylko nieznacznie większy, ponieważ autoprefixer dodał więcej prefiksów dostawców na podstawie wartości docelowej z 2016 r. Zwróć też uwagę na zmianę w zapytaniu Browserslist:

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

W porównaniu z wersją docelową „Podstawowa, szeroko dostępna” te wersje przeglądarek są znacznie starsze – na tyle, że wersja Edge, na którą kierujemy reklamy w tym przypadku, jest starsza niż Chromium.

Zmienią się też polyfille wstrzykiwane przez core-js, co jest znacznie większą zmianą niż w przypadku wybrania jako celu opcji „Podstawa powszechnie dostępna”:

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

Wniosek jest taki, że wartość docelowa Baseline może mieć znaczący wpływ na to, jak aplikacja zostanie przekształcona przez łańcuch narzędzi projektu. Aplikacja w tym przykładzie jest bardzo prosta i nie zawiera wielu najnowocześniejszych funkcji dla deweloperów w React ani w samej aplikacji. W przypadku znacznie bardziej złożonych aplikacji możesz spodziewać się zupełnie innych wyników – być może nawet większej liczby dodatkowych polyfilli, przekształceń i innych źródeł dodatkowego kodu, które pozwolą osiągnąć wybrany poziom bazowy.

5. Kierowanie na przeglądarki niższego poziomu za pomocą browserslist-config-baseline

Przypomnijmy, że podstawowy zestaw przeglądarek, na które kieruje Baseline, obejmuje te przeglądarki:

Chrome
Chrome na Androida
Firefox
Firefox na Androida
Edge
Safari na macOS
Safari na iOS

Możesz jednak kierować reklamy na tzw. przeglądarki podrzędne. Są to przeglądarki, których silniki pochodzą z przeglądarki z podstawowego zestawu przeglądarek, najczęściej z Chromium. Obejmują one przeglądarki takie jak Opera, Samsung Internet i inne. Możesz skonfigurować browserslist-config-baseline, aby kierować na nie reklamy w pliku package.json w ten sposób:

"browserslist": "extends browserslist-config-baseline/with-downstream"

Kierowanie jest wtedy realizowane na przeglądarki niższego poziomu zgodnie z ustawieniem „Podstawowe, powszechnie dostępne”. Aby sprawdzić, jak to przekłada się na zapytanie Browserslist, ponownie skompiluj projekt:

npm start

Następnie zwróć uwagę na zmianę w zapytaniu Browserslist:

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

Możesz też kierować reklamy na przeglądarki niższego poziomu według roku. Na przykład:

"browserslist": "extends browserslist-config-baseline/with-downstream/2016"

W tej konfiguracji zapytanie Browserslist zostanie odpowiednio zmienione:

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

6. Linters and other tools

browserslist-config-baseline to wygodne narzędzie dla bundlerów i innych części łańcucha narzędzi, ale warto też korzystać z innych narzędzi, takich jak lintery, które przyjęły cele Baseline jako część swojej konfiguracji.

Dobrym przykładem obsługi podstawowych zabezpieczeń przez linter jest ESLint, który w ramach lintingu CSS udostępnia use-baseline regułę korzystającą z @eslint/css, która umożliwia kierowanie na podstawowe zabezpieczenia nowo dostępne, powszechnie dostępne lub obowiązujące od lat. Podobna reguła znajduje się też w pakiecie społecznościowym @html-eslint/eslint-plugin, która pozwala zrobić to samo w przypadku funkcji HTML w pliku 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"
      }]
    }
  }
];

W tej konfiguracji warto zwrócić uwagę na kilka kwestii:

Zarówno pakiet do sprawdzania kodu HTML, jak i pakiet do sprawdzania kodu CSS używają reguły use-baseline, która jest ustawiona na „Widely available” (Szeroko dostępne) za pomocą opcji konfiguracji available: "widely".
W przypadku obu pakietów do sprawdzania kodu poziom logów dotyczących naruszeń jest ustawiony na "warn". Możesz ustawić wartość "error", aby przerwać proces z kodem błędu i zapobiec kompilacji.

Dane wyjściowe narzędzia do sprawdzania kodu mogły się już pojawiać podczas wykonywania polecenia npm run build, ale aby zobaczyć je osobno, możesz uruchomić to polecenie:

npm run lint

W wyświetlonych danych wyjściowych zobaczysz kilka ostrzeżeń dotyczących arkusza CSS projektu:

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

Jak widać, używanie browserslist-config-baseline w projekcie wymaga pewnej wiedzy o narzędziach do kompilacji i Browserslist, ale umieszczenie go w projektach powinno być możliwe po niewielkim wysiłku. Główną zaletą tej funkcji jest to, że nie musisz już myśleć o obsługiwanych przeglądarkach w kontekście numerów wersji, ale raczej o podstawowym celu, który wykonuje za Ciebie większość pracy.

Istnieje też wersja tej demonstracji, która działa w Rollup. Możesz też w dużej mierze korzystać z niej podczas wykonywania tego szkolenia.

Podstawowe wsparcie zaczyna się też pojawiać w innych narzędziach do łączenia. Na przykład Vite, który korzysta z Rollup, od wersji 7 domyślnie obsługuje przeglądarki zgodne z Baseline Widely available.

Niezależnie od tego, jak to zrobisz, wprowadzenie browserslist-config-baseline do łańcucha narzędzi projektu i wybranie odpowiedniego celu Baseline pozwoli Ci w prostszy i bardziej niezawodny sposób kierować reklamy na przeglądarki.