Prinzip und Implementierung der Verwendung des Webpack-Moduls zum Verpacken der Bibliothek

Dieser Artikel stellt hauptsächlich das Prinzip und die Implementierung der Webpack-Organisationsmodul-Verpackungsbibliothek vor. Jetzt teile ich ihn mit Ihnen und gebe ihn als Referenz.

In einem früheren Artikel wurden die Grundprinzipien der Webpack-Packung von JS-Modulen analysiert. Der vorgestellte Fall ist die häufigste Situation, dh mehrere JS-Module und ein Einstiegsmodul werden in eine Bundle-Datei gepackt, die direkt ausgeführt werden kann Durch einen Browser oder eine andere JavaScript-Engine entspricht dies einer direkten Kompilierung zum Generieren einer vollständigen ausführbaren Datei. Es gibt jedoch noch eine weitere sehr häufige Situation: Wir möchten beispielsweise eine JavaScript-Bibliothek erstellen und veröffentlichen. Wenn Sie beispielsweise Ihre eigene Bibliothek in der npm-Community veröffentlichen, muss Webpack entsprechend konfiguriert werden und der kompilierte Code unterscheidet sich geringfügig .

Wie der vorherige Artikel analysiert dieser Artikel hauptsächlich den generierten Code von Webpack und kombiniert ihn, um die spezifische Rolle der Bibliothekskonfigurationsoptionen von Webpack beim Kompilieren der Bibliothek zu erläutern. Die entsprechende offizielle Dokumentation finden Sie hier.

Bibliothek zum Schreiben von JS

Beginnen wir mit einem einfachen Fall. Wir schreiben einfach eine einfache Bibliothek util.js:

import $ from 'jquery'

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

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

export default {
 sayHello: sayHello,
 hideImages: hideImages
}

bietet zwei Funktionen, die natürlich nichts miteinander zu tun haben und eigentlich keinen Nutzen haben. Sie dienen lediglich der Unterrichtsreferenz. . .

Als nächstes schreiben Sie die Webpack-Konfiguration:

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

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

Aber das allein reicht nicht aus, die Ausgabedatei ist eine Funktion, die sofort ausgeführt wird. Endlich , die Exporte von util.js werden zurückgegeben. Die endgültige generierte Bundle-Codestruktur sieht ungefähr so ​​aus:

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

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

Wenn die Ausführung abgeschlossen ist, geben wir einfach den Exportteil von util.js zurück. Wir müssen diesen Rückgabewert an module.export der kompilierten Datei übergeben, damit die kompilierte Datei zu einer Datei wird, die ausgeführt werden kann von anderen importiert. Die kompilierte Datei, die wir zu erhalten hoffen, sollte also wie folgt aussehen:

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
});

Um ein solches Ergebnis zu erhalten, müssen die Bibliotheksinformationen zum Ausgabeteil von hinzugefügt werden die Webpack-Konfiguration:

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

 library: 'util',
 libraryTarget: commonjs2
}

Das Wichtigste hier ist das Bibliotheksziel. Da wir nun das commonjs2-Format verwenden, erhalten wir die oben genannten Kompilierungsergebnisse dass Webpack die Bibliothek verwendet, um die endgültige Ausgabe in das CommonJS-Formular zu konvertieren, wodurch die Veröffentlichung einer Bibliothek realisiert wird.

Andere Veröffentlichungsformate

Zusätzlich zu commonjs2 verfügt LibraryTarget über weitere Optionen:

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

Kompilieren Sie die Dateien mit verschiedenen Optionen kann in verschiedenen JavaScript-Ausführungsumgebungen verwendet werden. Hier sehen wir direkt, wie die Ausgabe des Tiger Balm umd-Formats aussieht:

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

ist viel komplizierter als die vorherige commonjs2-Situation, da verschiedene Dinge verarbeitet werden müssen Es gibt verschiedene Fälle, aber tatsächlich sind die folgenden Teile gleich. Das Wichtigste sind die ersten Zeilen. Dies ist die Standardmethode zum Schreiben des umd-Moduls. Es führt die übergebene Factory-Funktion aus, bei der es sich tatsächlich um die Funktion handelt, die das Modul lädt, und übergibt dann das zurückgegebene Ergebnis entsprechend den verschiedenen Betriebsumgebungen an das entsprechende Objekt. Beispielsweise legt var das Ergebnis als globale Variable fest, die vom Browser verwendet wird, um die JS-Datei direkt über das Tag 3f1c4e4b6b16bbbd69b2ee476dc4f83a zu importieren Da es sich um eine AMD-Umgebung handelt, wird auch Standard-AMD-Schreiben verwendet. Auf diese Weise kann die veröffentlichte JS-Bibliothek von anderen in jeder Umgebung verwendet werden.

targetExport steuert den Ausgabeinhalt

Wenn Sie zum Packen das umd-Format verwenden, gibt es möglicherweise eine Gefahr, auf die Sie achten müssen, wenn der Quellcode Ihrer Bibliothek im ES6-Format exportiert wird Standardmäßig exportieren, wie oben. Nehmen Sie util.js als Beispiel. Wenn Sie die kompilierte JS-Bibliotheksdatei direkt in den Browser einfügen und verwenden, erhalten Sie möglicherweise nicht die gewünschten Ergebnisse. Dies liegt daran, dass das Objekt, das Ihre JS-Datei an Sie zurückgibt, so aussieht:

{
 'default': {
  sayHello: sayHello,
  hideImages: hideImages
 }
}

und nicht wie erwartet:

{
 sayHello: sayHello,
 hideImages: hideImages
}

Dieses Problem tritt nicht nur in Browsern auf, sondern auch in Modulsystemen, die ES6 nicht unterstützen, da sie die Standardeinstellung nicht verstehen. Ihre kompilierte JS-Datei sollte also eigentlich nur den Standardwert ausgeben, der durch targetExport in der Webpack-Konfiguration gesteuert werden muss:

library: 'util',
libraryTarget: umd,
targetExport: 'default'

Auf diese Weise fügt die Modulladefunktionsfabrik oben einen ['default'] nach dem Rückgabewert hinzu, sodass nur der Standardteil der Exporte zurückgegeben wird.

Diese Falle lässt sich im umd-Format eigentlich ganz einfach umgehen. Wenn Sie beispielsweise eine Vue-Komponente veröffentlichen, exportiert der JavaScript-Teil in der .vue-Datei normalerweise das Komponentenobjekt im Export-Standardformat So:

export default {
 name: 'xxx',
 data: {
  return // ...
 },
 props: {
  // ...
 }
 methods: {
  // ...
 }
}

Wenn Sie die kompilierte JS-Datei direkt im Browser ausführen und CDN verwenden, um Vue über 3f1c4e4b6b16bbbd69b2ee476dc4f83a zu laden, werden Sie das finden Vue kann diese Komponente nicht erkennen, da das Objekt, das Sie erhalten, über eine zusätzliche Ebene unnötiger Standardeinstellungen verfügt.

Sie fragen sich vielleicht, ob es Auswirkungen auf die Verwendung dieses Moduls in der ES6-Umgebung hat, wenn ich den Ausgabeinhalt auf den Standardwert ändere? Generell nein. Wie in einem früheren Artikel erwähnt, legt der generierte Code von Webpack ein Modul fest und bestimmt, ob es sich um einen Export im ES6-Format handelt, und zwar über einen Wert namens __esModule. Wenn nun nur der Standardteil exportiert wird, wird dieses Objekt als Nicht-Modul betrachtet. ES6, da es __esModule nicht enthält. Wenn andere Module dieses Modul durch Import einführen, wird auf diese Weise das gesamte Objekt importiert, was tatsächlich dem Import nur des getarnten Exportstandardteils des Originalmoduls entspricht.

Natürlich geht die obige Diskussion davon aus, dass alle Inhalte, die Sie exportieren müssen, standardmäßig exportiert werden. Wenn Sie sowohl den Standard- als auch den Normalexport haben, ist es offensichtlich nicht möglich, dass die kompilierte Datei nur den Standardteil exportiert.

Ich habe das Obige für Sie zusammengestellt und hoffe, dass es Ihnen in Zukunft hilfreich sein wird.

Verwandte Artikel:

200 Zeilen Code zur Implementierung der Blockchain Detaillierte Erklärung von Blockchain-Beispielen

Vue nutzt Facebook Twitter, um Beispiele teilen

React erstellt ein Projekt basierend auf Create-React-App

Das obige ist der detaillierte Inhalt vonPrinzip und Implementierung der Verwendung des Webpack-Moduls zum Verpacken der Bibliothek. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!