Shimming: esensya, mga pamamaraan, at prinsipyo ng paggana

Ano ang Shimming?

Shimming ay isang software na teknik na naglalagay ng layer ng compatibility sa pagitan ng code at ng kapaligiran, nang hindi binabago ang source code ng module. Sa konteksto ng JavaScript bundling, nilulutas ng shimming ang problema kapag tumutukoy ang module sa mga pandaigdigang variable (window.$, global.process) na wala sa modular na kapaligiran.

Shim at polyfill: mga pangunahing pagkakaiba

Polyfill ay nagpapatupad ng nawawalang functionality mula sa simula, nagdaragdag ng mga bagong kakayahan sa kapaligiran. Halimbawa, ang core-js ay nagdaragdag ng Array.prototype.flatMap para sa mga lumang browser. Shim naman ay nire-redirect ang mga umiiral na tawag sa mga magagamit na implementasyon o pinapalitan ang inaasahang pandaigdigang bagay. Sa Webpack, awtomatikong nagsisingit ang ProvidePlugin ng import $ from 'jquery' kahit saan may pagtukoy sa pandaigdigang variable na $, nang hindi nangangailangan ng mga pagbabago sa code.

Ang pangunahing pagkakaiba ay nasa layunin. Polyfill ay nagdaragdag ng wala, samantalang shim ay ginagawang compatible ang umiiral na code sa kapaligiran kung saan ito pinapatakbo. Ang pagpili sa pagitan nila ay nakasalalay sa problemang nilulutas: ang kawalan ng API o ang incompatibility ng mga interface.

Paano gumagana ang Shimming sa Webpack

Webpack ay tinatrato ang bawat module bilang nakahiwalay na yunit na may sariling saklaw ng visibility. Kung tumutukoy ang isang library sa pandaigdigang variable na jQuery bilang window.$, magtatapos ang bundling sa isang error, dahil wala ang variable na ito sa modular na konteksto. ProvidePlugin ay nilulutas ang problema sa yugto ng compilation: kapag nakakita ng identifier na $ sa code, awtomatikong nagsisingit ang plugin ng import $ from 'jquery' sa simula ng file.

// Source code (ang legacy module ay tumutukoy sa global na jQuery)
$('.element').hide();

// Pagkatapos iproseso ng ProvidePlugin (nagsisingit ang Webpack ng import)
import $ from 'jquery';
$('.element').hide();

Bilang karagdagan, ang imports-loader ay nagpapahintulot sa malinaw na pagtukoy kung aling mga dependency ang dapat matanggap ng module. Kapaki-pakinabang ito kapag gumagamit ang library ng this sa pinakamataas na antas, inaasahang tumutukoy ang this sa window, hindi sa module.exports.

ProvidePlugin: mga pandaigdigang variable para sa mga module

ProvidePlugin — isang built-in na Webpack plugin na awtomatikong naglo-load ng mga module kapag may nakitang pagtukoy sa mga tinukoy na identifier. Ang configuration ay isang object kung saan ang key ay ang pangalan ng variable, at ang value ay ang landas patungo sa module at sa naka-export na field.

Configuration ng plugin

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

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

ProvidePlugin ay sumusuporta sa naka-target na pag-import sa pamamagitan ng array syntax. Halimbawa, ang [lodash, debounce] ay nag-i-import lamang ng function na debounce mula sa lodash, na nagpapaliit sa laki ng huling bundle. Ito ay lalong mahalaga para sa mga mobile project, kung saan ang bawat kilobyte ay nakakaapekto sa oras ng pag-load.

imports-loader at exports-loader

imports-loader ay nagdaragdag ng mga kinakailangang import sa simula ng module, habang ang exports-loader ay nagtatakda ng mga naka-export na halaga para sa mga module na hindi tahasang gumagamit ng module.exports. Ang mga loader na ito ay gumagana sa antas ng mga indibidwal na file, hindi globally tulad ng ProvidePlugin.

Pag-aayos ng mga dependency gamit ang imports-loader

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

exports-loader ay ginagamit kapag nagtatalaga ang library ng halaga sa isang pandaigdigang variable, ngunit hindi ito ini-export sa pamamagitan ng sistema ng module. Kinukuha ng loader ang halaga at ginagawa itong modular export, na nagpapahintulot sa ibang mga module na i-import ito sa pamamagitan ng import.

Pag-configure ng shimming sa Webpack configuration

Shimming ay ina-configure sa webpack.config.js sa pamamagitan ng kombinasyon ng mga plugin at loader. Ang karaniwang senaryo ay may kasamang ProvidePlugin para sa mga pandaigdigang variable at imports-loader para sa mga partikular na module na nangangailangan ng pagbabago sa saklaw ng visibility.

Batayang Webpack configuration para sa shimming

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',
    }),
  ],
};

Ang field na globalObject sa output ay nagtatakda ng konteksto para sa mga pagtukoy sa this sa pinakamataas na antas. Para sa browser na kapaligiran, ang halagang 'this' ay tumutukoy sa window, at para sa React Native o Node.js — sa global. Ang pagpili ng tamang halaga ay pumipigil sa mga error sa pagpapatakbo sa target na kapaligiran.

Mga karaniwang pagkakamali sa shimming

Shimming ay isang makapangyarihan, ngunit mapanganib na tool. Ang maling configuration ay humahantong sa pagdoble ng code sa bundle, mga salungatan sa pangalan, at mga hindi inaasahang error sa pagpapatakbo. Madalas nakakalimutan ng mga developer na gumagana ang ProvidePlugin sa yugto ng compilation at hindi kayang iproseso ang mga dynamic na pagtukoy sa mga variable.

Mga salungatan sa pandaigdigang variable

Kung ang dalawang plugin ay gumagamit ng magkaibang bersyon ng jQuery, ang ProvidePlugin ay magsisingit lamang ng isa sa kanila, ang unang tinukoy sa configuration. Ang pangalawang library ay makakatanggap ng hindi tugmang bersyon, na magdudulot ng mga error na mahirap i-debug. Ang solusyon ay ang paggamit ng exports-loader para sa bawat library na may malinaw na pagtukoy ng bersyon o paglalapat ng webpack.IgnorePlugin para ibukod ang mga duplicate na module.

Ang isa pang karaniwang pagkakamali ay ang pagtatangkang i-shim ang mga module na gumagamit ng synchronous na CommonJS na mga tawag na require sa dynamic na konteksto. Ang ProvidePlugin ay nagpoproseso lamang ng mga static na identifier, kaya ang mga dynamic na pagtukoy ay dapat palitan nang manu-mano o gamitin ang NormalModuleReplacementPlugin.

Mga problema sa performance sa maling shimming

Ang maling configuration ng shimming ay maaaring humantong sa malaking paglaki ng laki ng bundle. Kung ang ProvidePlugin ay naka-configure para sa dose-dosenang pandaigdigang variable, ang Webpack ay magsisingit ng mga katumbas na import sa lahat ng file ng project, anuman ang paggamit ng mga variable na ito sa bawat partikular na file. Lumilikha ito ng labis na code, lalo na sa malalaking project na may libu-libong module.

Para ma-diagnose ang mga problema sa shimming, gamitin ang webpack-bundle-analyzer — isang tool para sa pag-visualize ng komposisyon ng bundle. Kung ang jQuery o ibang library ay lumalabas nang ilang beses sa bundle, malamang nagkakasalungatan ang magkaibang bersyon o ang ProvidePlugin ay naka-configure para sa ilang identifier na humahantong sa magkaibang bersyon ng package. Ang solusyon ay ang pag-isa ng mga bersyon ng dependency sa pamamagitan ng resolve.alias at ang pagtiyak na ang lahat ng na-shim na identifier ay tumuturo sa parehong module.

Mga alternatibo sa shimming: refactoring at pag-update ng mga dependency

Bago ilapat ang shimming, suriin ang posibilidad na i-update ang library sa bersyon na sumusuporta sa sistema ng module. Maraming legacy package ang may modernong alternatibo na hindi nangangailangan ng shimming. Halimbawa, ang mga jQuery plugin ay maaaring palitan ng mga native browser API: $.ajax → fetch, $.each → Array.forEach. Ang refactoring ay nagbibigay ng pangmatagalang pakinabang sa pagpapanatili, samantalang ang shimming ay isang pansamantalang solusyon na nagpapakumplikado sa configuration.

Kung hindi posible ang pag-update, isaalang-alang ang NormalModuleReplacementPlugin, na nagpapahintulot sa pagpapalit ng isang module ng isa pa sa antas ng resolution, nang hindi binabago ang source code. Ang plugin na ito ay gumagana sa yugto ng pagbuo ng dependency graph, bago ilapat ang mga loader, at pinoproseso ang lahat ng pagtukoy sa module anuman ang konteksto. Ito ay mas malinis na solusyon para sa pagpapalit ng buong library kaysa sa mga naka-target na loader.

Shimming sa modernong JavaScript: ESM at import maps

Sa pag-unlad ng native na ES modules sa mga browser at sa pagdating ng import maps, ang ilang shimming na senaryo ay maaaring malutas nang walang Webpack. Pinapahintulutan ng import maps ang pagtatalaga muli ng mga pangalan ng module sa antas ng browser, nang walang yugto ng bundling. Gayunpaman, ang pamamaraang ito ay hindi sinusuportahan sa React Native at iba pang kapaligiran na walang browser ESM, kaya nananatiling mahalaga ang shimming sa pamamagitan ng Webpack para sa production bundle na nangangailangan ng buong kontrol sa mga dependency at sa kanilang mga bersyon. Ang pagpili sa pagitan ng import maps at Webpack shim ay nakasalalay sa target na platform at sa mga kinakailangan para sa compatibility sa mga lumang browser.