Principe et implémentation de l'utilisation du module webpack pour empaqueter la bibliothèque-js tutoriel-php.cn

Cet article présente principalement le principe et la mise en œuvre de la bibliothèque d'empaquetage du module d'organisation webpack. Maintenant, je le partage avec vous et le donne comme référence.

Un article précédent a analysé les principes de base du packaging des modules JS par Webpack. Le cas présenté est la situation la plus courante, c'est-à-dire que plusieurs modules JS et un module d'entrée sont regroupés dans un fichier bundle, qui peut être directement exécuté. par un navigateur ou autre moteur JavaScript, cela équivaut à une compilation directe pour générer un fichier exécutable complet. Cependant, il existe une autre situation très courante : nous souhaitons créer et publier une bibliothèque JavaScript. Par exemple, si vous publiez votre propre bibliothèque dans la communauté npm, Webpack a besoin d'une configuration correspondante et le code compilé sera légèrement différent. .

Comme l'article précédent, cet article analyse principalement le code généré de Webpack, et le combine pour expliquer le rôle spécifique des options de configuration de la bibliothèque de Webpack lors de la compilation de la bibliothèque. La documentation officielle correspondante est ici.

Bibliothèque pour écrire du JS

Commençons par un cas simple Nous écrivons simplement une bibliothèque simple util.js :

import $ from &#39;jquery&#39;

function sayHello() {
 console.log("Hello");
}

function hideImages() {
 $(&#39;img&#39;).hide();
}

export default {
 sayHello: sayHello,
 hideImages: hideImages
}

Copier après la connexion

fournit deux fonctions. Bien sûr, elles n'ont rien à voir l'une avec l'autre et ne sont en réalité d'aucune utilité. Elles sont uniquement à titre de référence pédagogique. . .

Écrivez ensuite la configuration de Webpack :

// 入口文件
entry: {
 util: &#39;./util.js&#39;,
}

// 输出文件
output: {
 path: &#39;./dist&#39;,
 filename: &#39;[name].dist.js&#39;
}

Copier après la connexion

Mais cela seul ne suffit pas, le fichier de sortie sera exécuté immédiatement, la fonction sera renvoie enfin les exportations de util.js En vous référant à l'analyse de l'article précédent, la structure finale du code du bundle généré ressemble à ceci :

(function(modules) {
 var installedModules = {};
 
 function webpack_require(moduleId) {
   // ...
 }

 return webpack_require(&#39;./util.js&#39;);
}) ({
 &#39;./util.js&#39;: generated_util,
 &#39;/path/to/jquery.js&#39;: generated_jquery
});

Copier après la connexion

. S'il est exécuté, c'est fini. Il renvoie uniquement la partie export de util.js. Ce dont nous avons besoin est de donner cette valeur de retour au module.export du fichier compilé, afin que le fichier compilé devienne une bibliothèque pouvant être utilisée. importés par d'autres. Le fichier compilé que nous espérons obtenir devrait donc ressembler à ceci :

module.exports = (function(modules) {
 var installedModules = {};
 function webpack_require(moduleId) {
   // ...
 }
 return webpack_require(&#39;./util.js&#39;);
}) ({
 &#39;./util.js&#39;: generated_util,
 &#39;/path/to/jquery.js&#39;: generated_jquery
});

Copier après la connexion

Pour obtenir un tel résultat, les informations de la bibliothèque doivent être ajoutées à la sortie. fait partie de la configuration du Webpack :

// 入口文件
output: {
 path: &#39;./dist&#39;,
 filename: &#39;[name].dist.js&#39;,

 library: &#39;util&#39;,
 libraryTarget: commonjs2
}

Copier après la connexion

La chose la plus importante ici est libraryTarget. Si nous utilisons maintenant le format commonjs2, nous obtiendrons le résultat de compilation ci-dessus. , ce qui signifie que Webpack bibliothèquera la dernière La sortie est exportée sous forme de CommonJS, réalisant ainsi la sortie d'une bibliothèque.

Autres formats de publication

En plus de commonjs2, libraryTarget propose d'autres options :

var (默认值，发布为全局变量)
commonjs
commonjs2
amd
umd

Copier après la connexion

Utiliser différentes options, Les fichiers compilés peuvent être utilisés dans différents environnements d'exécution JavaScript. Ici, nous regardons directement la sortie du format umd d'huile de serpent :

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

Copier après la connexion

C'est beaucoup plus compliqué que la situation précédente commonjs2 car elle nécessite des poignées diverses cas différents, mais en fait les parties suivantes sont les mêmes. Les plus importantes sont les premières lignes. C'est la manière standard d'écrire le module umd. Il exécute la fonction d'usine transmise, qui est en fait la fonction qui charge le module, puis transmet le résultat renvoyé à l'objet correspondant en fonction des différents environnements d'exploitation. Par exemple, var définira le résultat comme une variable globale, qui est utilisée par le navigateur pour importer directement le fichier JS via la balise

Derniers articles par auteur