Comment utiliser le module externe dans webpack

Cet article présente principalement l'utilisation spécifique du module externe webpack. Maintenant, je le partage avec vous et vous donne une référence.

Cet article traite d'une option externe qui est souvent utilisée lorsque Webpack emballe des bibliothèques. Elle est utilisée pour éviter d'empaqueter certains modules très courants dans la bibliothèque que vous publiez, et choisit à la place de les déclarer comme module externe, après votre. La bibliothèque est utilisée par la couche supérieure, Webpack emballera les modules dépendants externes dans l'étape finale.

L'option externe est généralement utilisée pour empaqueter des bibliothèques. S'il ne s'agit pas d'une bibliothèque mais d'un fichier JS de version finale de l'application, alors externe n'a aucune signification. Concernant l'analyse de la bibliothèque de packaging Webpack et le rôle de certaines options, j'en ai parlé dans l'article précédent.

option externe

Nous utilisons toujours l'exemple de l'article précédent et définissons une bibliothèque util.js :

import $ from 'jquery'

function hideImages() {
 $('img').hide();
}

export default {
 "hideImages": hideImages
}

Nous utilisons Webpack pour packaging Publiez cette bibliothèque :

// 入口文件
entry: {
 util: './util.js',
}

// 输出文件
output: {
 path: './dist',
 filename: '[name].dist.js'

 library: 'util',
 libraryTarget: commonjs2,
 targetExport: 'default'
}

Le fichier util.dist.js ainsi packagé y injectera complètement du code jquery, car votre code source l'utilise. Mais ce n'est souvent pas ce que nous voulons, car jquery est un module très courant dans une application, d'autres bibliothèques peuvent également l'utiliser. L'application de fichier d'entrée de niveau supérieur peut également l'utiliser si chaque module de bibliothèque est publié. emballez jquery intact dans leurs propres bundles, et enfin rassemblez-les. Il y aura de nombreuses copies de jquery dans le code de version finale de l'application. Bien sûr, cela peut ne pas affecter son fonctionnement normal, mais cela occupera une grande taille de code.

Donc, généralement, lorsque votre bibliothèque doit dépendre de modules JS courants tels que jquery et bootstrap, nous ne pouvons pas la regrouper dans un bundle, mais la déclarer externe dans la configuration du Webpack :

externals: {
 jquery: {
  root: 'jquery',
  commonjs: 'jquery',
  commonjs2: 'jquery',
  amd: 'jquery',
 },
},

Cela indique à Webpack : veuillez ne pas injecter ce module dans le fichier JS compilé. Veuillez conserver toutes les instructions import/require de ce module qui apparaissent dans mon code source.

Nous pouvons jeter un œil à la structure du fichier bundle compilé :

module.exports = (function(modules) {
 var installedModules = {};
 function webpack_require(moduleId) {
   // ...
 }
 return webpack_require('./util.js');
}) ({
 './util.js': generated_util,
 // '/path/to/jquery.js': generated_jquery 原本有这一行，现在被删去。
});

Vous pouvez voir que le module jquery n'est pas packagé dans le fichier bundle, et pour util, il est généré code est la fonction générée_util. Les instructions liées à import jquery ont également conservé leur sens d'origine :

function generated_util(module, exports, webpack_require) {
 var $ = require('jquery');
 // util的其它源代码
 // ...
}

Bien sûr, elles ne sont pas complètement inchangées. Par exemple, l'importation revient au mot-clé require traditionnel, car nous utilisons ici la méthode d'empaquetage de style CommonJS. Mais ceux-ci sont mineurs. La clé est qu'il conserve le mot-clé require et n'utilise pas webpack_require pour réellement introduire jquery. Cela signifie qu'il n'y a pas de jquery dans le système de gestion de module actuel de ce fichier JS. C'est un module externe qui ne peut être réellement introduit que lorsque ce fichier JS est référencé par d'autres et compilé au niveau supérieur. Le mot-clé require ici sera remplacé par webpack_require.

Pour les modules de dépendances externes, vous pouvez généralement le faire. Par exemple, si vous utilisez npm pour publier votre bibliothèque, vous pouvez ajouter jquery aux dépendances dans le fichier package.json, de sorte que lorsque d'autres npm installent la bibliothèque. vous avez publié, jquery sera également automatiquement téléchargé sur node_modules pour que d'autres puissent l'emballer et l'utiliser.

Packaging au format umd

Si nous utilisons un packaging au format umd, nous pouvons voir comment le module externe fonctionne dans différents environnements :

(function webpackUniversalModuleDefinition(root, factory) {
 if(typeof exports === 'object' && typeof module === 'object') // commonjs2
  module.exports = factory(require('jquery'));
 else if(typeof define === 'function' && define.amd)
  define("util", ['jquery'], factory); // amd
 else if(typeof exports === 'object')
  exports["util"] = factory(require('jquery')); // commonjs
 else
  root["util"] = factory(root['jquery']); // var
}) (window, function(__webpack_external_module_jquery__) {
 return (function(modules) {
  var installedModules = {};
  function webpack_require(moduleId) {
    // ...
  }
  return webpack_require('./util.js');
 }) ({
  './util.js': generated_util,
 });
}

Generated_util ajoute également un paramètre __webpack_external_module_jquery__ en conséquence :

function generated_util(module, exports, webpack_require,
            __webpack_external_module_jquery__) {
 var $ = __webpack_external_module_jquery__;
 // util的其它源代码
 // ...
}

Cette façon d'écrire semble avoir une structure différente de la version compilée de CommonJS ci-dessus, mais en fait l'essence est la même. Parce que umd doit maintenant prendre en charge différents environnements d'exploitation, il avance require('jquery') et le transmet comme paramètre de l'usine. Pour chaque environnement d'exploitation, chacun a sa propre approche :

1. CommonJS : conserver l'instruction require('jquery').

2. AMD : définissez jquery comme module dépendant dans définir.

3. Var : Prenez la variable jquery du domaine global, ce qui nécessite que jquery soit chargé avant le module.

Ensuite, quelle que soit la situation, ils transmettront le module jquery chargé en tant que paramètre dans la fonction d'usine, afin que le module util puisse être chargé correctement.

La partie ci-dessus impliquant le code généré par Webpack peut être un peu alambiquée. Vous devez avoir une meilleure compréhension du mécanisme et du principe du module de packaging Webpack. J'ai discuté de cette partie en détail dans cet article.

Résumé

Ce qui précède concerne l'utilisation de l'option externe de Webpack, et son fonctionnement est analysé à partir du code JS compilé. Je pense qu'il est toujours très important de lire le code généré lié à Webpack, afin que vous puissiez vraiment comprendre le mécanisme externe et savoir comment déboguer lorsque vous rencontrez des pièges.

J'ai compilé ce qui précède pour vous, j'espère que cela vous sera utile à l'avenir.

Articles associés :

Exemple de définition de votre propre composant de temps angulaire basé sur le sélecteur de date

Résoudre Vue.js 2.0 parfois bidirectionnel Le problème de l'échec de la liaison de l'attribut img src

Vue.js attribue dynamiquement une valeur au src d'img

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!