Shimming: istota, podejścia i zasada działania

Czym jest Shimming?

Shimming to technika programowa, która wbudowuje warstwę zgodności między kodem a środowiskiem, nie zmieniając kodu źródłowego modułu. W kontekście budowania JavaScript shimming rozwiązuje problem, gdy moduł odwołuje się do zmiennych globalnych (window.$, global.process), których nie ma w środowisku modułowym.

Shim i polyfill: podstawowe różnice

Polyfill implementuje brakującą funkcjonalność od zera, dodając nowe możliwości do środowiska. Na przykład core-js dodaje Array.prototype.flatMap dla starych przeglądarek. Shim natomiast przekierowuje istniejące wywołania na dostępne implementacje lub podmienia oczekiwane obiekty globalne. W Webpack ProvidePlugin automatycznie wstawia import $ from 'jquery' wszędzie tam, gdzie występuje odwołanie do zmiennej globalnej $, nie wymagając zmian w kodzie.

Podstawowa różnica polega na celu. Polyfill dodaje to, czego nie ma, a shim sprawia, że istniejący kod staje się zgodny ze środowiskiem, w którym jest wykonywany. Wybór między nimi zależy od tego, jaki problem jest rozwiązywany: brak API czy niezgodność interfejsów.

Jak działa Shimming w Webpack

Webpack traktuje każdy moduł jako izolowaną jednostkę z własnym zakresem widoczności. Jeśli biblioteka odwołuje się do zmiennej globalnej jQuery jako do window.$, budowanie zakończy się błędem, ponieważ w kontekście modułowym tej zmiennej nie ma. ProvidePlugin rozwiązuje problem na etapie kompilacji: po wykryciu identyfikatora $ w kodzie wtyczka automatycznie wstawia import $ from 'jquery' na początku pliku.

// Kod źródłowy (moduł legacy odwołuje się do globalnej jQuery)
$('.element').hide();

// Po przetworzeniu przez ProvidePlugin (Webpack wstawia import)
import $ from 'jquery';
$('.element').hide();

Dodatkowo imports-loader pozwala jawnie określić, jakie zależności powinien otrzymywać moduł. Jest to przydatne, gdy biblioteka używa this na najwyższym poziomie, oczekując, że this odnosi się do window, a nie do module.exports.

ProvidePlugin: zmienne globalne dla modułów

ProvidePlugin — wbudowana wtyczka Webpack, która automatycznie wczytuje moduły po wykryciu odwołania do określonych identyfikatorów. Konfiguracja to obiekt, w którym klucz to nazwa zmiennej, a wartość to ścieżka do modułu i eksportowane pole.

Konfiguracja wtyczki

// webpack.config.js
const webpack = require('webpack');

module.exports = {
  plugins: [
    new webpack.ProvidePlugin({
      $: 'jquery',
      jQuery: 'jquery',
      _: 'lodash',
      'window.$': 'jquery',
    }),
  ],
};

ProvidePlugin obsługuje import punktowy przez składnię tablicową. Na przykład [lodash, debounce] importuje tylko funkcję debounce z lodash, co zmniejsza rozmiar końcowego pakietu. Jest to szczególnie ważne w projektach mobilnych, gdzie każdy kilobajt wpływa na czas ładowania.

imports-loader i exports-loader

imports-loader dodaje niezbędne importy na początku modułu, a exports-loader — ustawia eksportowane wartości dla modułów, które nie używają jawnie module.exports. Te loadery działają na poziomie pojedynczych plików, a nie globalnie, jak ProvidePlugin.

Naprawianie zależności za pomocą imports-loader

// webpack.config.js — konfiguracja imports-loader
module.exports = {
  module: {
    rules: [
      {
        test: /legacy-module\.js$/,
        use: [
          {
            loader: 'imports-loader',
            options: {
              imports: [
                'jquery',
                '$',
              ],
            },
          },
        ],
      },
    ],
  },
};

exports-loader jest używany, gdy biblioteka przypisuje wartość zmiennej globalnej, ale nie eksportuje jej przez system modułów. Loader wyodrębnia wartość i zamienia ją na eksport modułowy, co pozwala innym modułom importować ją przez import.

Konfiguracja shimmingu w konfiguracji Webpack

Shimming jest konfigurowany w webpack.config.js przez kombinację wtyczek i loaderów. Typowy scenariusz obejmuje ProvidePlugin dla zmiennych globalnych i imports-loader dla konkretnych modułów, które wymagają zmiany zakresu widoczności.

Podstawowa konfiguracja Webpack dla shimmingu

const webpack = require('webpack');
const path = require('path');

module.exports = {
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js',
    globalObject: 'this',
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules\/(?!legacy-lib)/,
        use: [
          {
            loader: 'imports-loader',
            options: {
              type: 'commonjs',
              imports: ['jquery', '$'],
            },
          },
        ],
      },
    ],
  },
  plugins: [
    new webpack.ProvidePlugin({
      $: 'jquery',
      jQuery: 'jquery',
    }),
  ],
};

Pole globalObject w output ustawia kontekst dla odwołań do this na najwyższym poziomie. Dla środowiska przeglądarki wartość 'this' odnosi się do window, a dla React Native lub Node.js — do global. Wybór prawidłowej wartości zapobiega błędom wykonania w środowisku docelowym.

Typowe błędy przy shimmingu

Shimming — potężne, ale niebezpieczne narzędzie. Nieprawidłowa konfiguracja prowadzi do duplikacji kodu w pakiecie, konfliktów nazw i nieoczekiwanych błędów wykonania. Programiści często zapominają, że ProvidePlugin działa na etapie kompilacji i nie może obsłużyć dynamicznych odwołań do zmiennych.

Konflikty zmiennych globalnych

Jeśli dwie wtyczki używają różnych wersji jQuery, ProvidePlugin wstawi tylko jedną z nich, wskazaną jako pierwszą w konfiguracji. Druga biblioteka otrzyma niezgodną wersję, co spowoduje trudne do zdebugowania błędy. Rozwiązaniem jest użycie exports-loader dla każdej biblioteki z jawnym wskazaniem wersji lub zastosowanie webpack.IgnorePlugin w celu wykluczenia zduplikowanych modułów.

Kolejnym częstym błędem jest próba shimmowania modułów, które używają synchronicznych wywołań CommonJS require w kontekście dynamicznym. ProvidePlugin obsługuje tylko statyczne identyfikatory, dlatego dynamiczne odwołania należy zastępować ręcznie lub używać NormalModuleReplacementPlugin.

Problemy z wydajnością przy nieprawidłowym shimmingu

Nieprawidłowa konfiguracja shimmingu może prowadzić do znacznego zwiększenia rozmiaru pakietu. Jeśli ProvidePlugin jest skonfigurowany na dziesiątki zmiennych globalnych, Webpack będzie wstawiał odpowiednie importy do wszystkich plików projektu, niezależnie od tego, czy te zmienne są używane w danym pliku. Tworzy to zbędny kod, zwłaszcza w dużych projektach z tysiącami modułów.

Do diagnozowania problemów z shimmingiem używaj webpack-bundle-analyzer — narzędzia do wizualizacji składu pakietu. Jeśli jQuery lub inna biblioteka pojawia się w pakiecie kilka razy, prawdopodobnie kolidują różne wersje lub ProvidePlugin jest skonfigurowany na kilka identyfikatorów prowadzących do różnych wersji pakietu. Rozwiązaniem jest ujednolicenie wersji zależności przez resolve.alias i sprawdzenie, czy wszystkie shimmowane identyfikatory wskazują ten sam moduł.

Alternatywy dla shimmingu: refaktoryzacja i aktualizacja zależności

Przed zastosowaniem shimmingu oceń możliwość aktualizacji biblioteki do wersji obsługującej system modułów. Wiele pakietów legacy ma nowoczesne alternatywy, które nie wymagają shimmowania. Na przykład wtyczki jQuery można zastąpić natywnymi API przeglądarki: $.ajax → fetch, $.each → Array.forEach. Refaktoryzacja daje długoterminową korzyść w utrzymaniu, podczas gdy shimming to rozwiązanie tymczasowe, które komplikuje konfigurację.

Jeśli aktualizacja nie jest możliwa, rozważ NormalModuleReplacementPlugin, który pozwala podmienić jeden moduł na inny na poziomie rozwiązywania, bez zmiany kodu źródłowego. Ta wtyczka działa na etapie budowania grafu zależności, przed zastosowaniem loaderów, i obsługuje wszystkie odwołania do modułu niezależnie od kontekstu. To czystsze rozwiązanie do zastępowania całych bibliotek niż punktowe loadery.

Shimming we współczesnym JavaScript: ESM i import maps

Wraz z rozwojem natywnych modułów ES w przeglądarkach i pojawieniem się import maps niektóre scenariusze shimmingu mogą zostać rozwiązane bez Webpack. Import maps pozwalają na bieżąco przypisywać nazwy modułów na poziomie przeglądarki, bez etapu budowania. Jednak to podejście nie jest obsługiwane w React Native i innych środowiskach bez ESM przeglądarki, dlatego shimming przez Webpack pozostaje aktualny w budowaniu produkcyjnym, gdzie wymagana jest pełna kontrola nad zależnościami i ich wersjami. Wybór między import maps a shimami Webpack zależy od platformy docelowej i wymagań dotyczących zgodności ze starymi przeglądarkami.