In diesem Artikel wird hauptsächlich die spezifische Verwendung des externen Webpack-Moduls vorgestellt. Jetzt werde ich es mit Ihnen teilen und Ihnen eine Referenz geben.
In diesem Artikel wird eine externe Option besprochen, die häufig verwendet wird, wenn Webpack-Bibliotheken gepackt werden. Sie wird verwendet, um das Packen einiger sehr häufiger Module in die von Ihnen veröffentlichte Bibliothek zu vermeiden, und deklariert sie stattdessen als externes Modul Wenn die Bibliothek von der oberen Ebene verwendet wird, verpackt Webpack in der letzten Phase die externen abhängigen Module.
Die externe Option wird im Allgemeinen zum Packen von Bibliotheken verwendet. Wenn es sich nicht um eine Bibliothek, sondern um eine endgültige App-Release-JS-Datei handelt, hat external keine Bedeutung. Was die Analyse der Webpack-Verpackungsbibliothek und die Rolle einiger Optionen betrifft, habe ich sie im vorherigen Artikel besprochen.
externe Option
Wir verwenden immer noch das Beispiel aus dem vorherigen Artikel, um eine Bibliothek util.js zu definieren:
import $ from 'jquery'
function hideImages() {
$('img').hide();
}
export default {
"hideImages": hideImages
}Wir verwenden Webpack zum Verpacken und Veröffentlichen Sie diese Bibliothek:
// 入口文件
entry: {
util: './util.js',
}
// 输出文件
output: {
path: './dist',
filename: '[name].dist.js'
library: 'util',
libraryTarget: commonjs2,
targetExport: 'default'
}Die auf diese Weise gepackte Datei util.dist.js fügt den JQuery-Code vollständig ein, da Ihr Quellcode ihn verwendet. Dies ist jedoch häufig nicht das, was wir wollen, da JQuery ein sehr verbreitetes Modul in einer App ist. Es kann auch von anderen Bibliotheken verwendet werden Packen Sie jquery in ihre eigenen Bundles und fügen Sie sie schließlich zusammen. Der endgültige App-Release-Code wird sich natürlich nicht auf seine normale Funktion auswirken.
Wenn Ihre Bibliothek also von gängigen JS-Modulen wie JQuery und Bootstrap abhängig sein muss, können wir sie normalerweise nicht in ein Bundle packen, sondern in der Webpack-Konfiguration als extern deklarieren:
externals: {
jquery: {
root: 'jquery',
commonjs: 'jquery',
commonjs2: 'jquery',
amd: 'jquery',
},
},Das ist Webpack mitteilen: Bitte fügen Sie dieses Modul nicht in die kompilierte JS-Datei ein. Bitte behalten Sie alle Import-/Require-Anweisungen dieses Moduls bei, die in meinem Quellcode erscheinen.
Wir können einen Blick auf die Struktur der kompilierten Bundle-Datei werfen:
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 原本有这一行，现在被删去。
});Sie können sehen, dass das JQuery-Modul nicht in die Bundle-Datei gepackt ist, für util jedoch der generierte Code Die Funktion „generated_util“ hat auch ihre ursprüngliche Bedeutung beibehalten:
function generated_util(module, exports, webpack_require) {
var $ = require('jquery');
// util的其它源代码
// ...
}Natürlich ist sie nicht völlig unverändert. Beispielsweise wird der Import wieder auf das traditionelle Schlüsselwort „require“ geändert, weil wir es sind Verwenden Sie hier die Verpackungsmethode im CommonJS-Stil. Diese sind jedoch geringfügig. Der Schlüssel liegt darin, dass das Schlüsselwort „require“ beibehalten wird und webpack_require nicht verwendet wird, um jquery wirklich einzuführen. Dies bedeutet, dass es im aktuellen Modulverwaltungssystem dieser JS-Datei keine wirkliche Einführung gibt, wenn diese JS-Datei zu diesem Zeitpunkt referenziert und kompiliert wird Das Schlüsselwort require wird hier durch webpack_require ersetzt.
Für externe abhängige Module können Sie dies normalerweise tun. Wenn Sie beispielsweise npm zum Veröffentlichen Ihrer Bibliothek verwenden, können Sie jquery zu Abhängigkeiten in der Datei package.json hinzufügen, damit andere npm die Bibliothek installieren Die von Ihnen veröffentlichte JQuery wird auch automatisch auf node_modules heruntergeladen, damit andere sie verpacken und verwenden können.
Verpackung im umd-Format
Wenn wir die Verpackung im umd-Format verwenden, können wir sehen, wie das externe Modul in verschiedenen Umgebungen funktioniert:
(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,
});
}Und generic_util Fügen Sie außerdem einen entsprechenden Parameter __webpack_external_module_jquery__ hinzu :
function generated_util(module, exports, webpack_require,
__webpack_external_module_jquery__) {
var $ = __webpack_external_module_jquery__;
// util的其它源代码
// ...
}Diese Schreibweise scheint eine andere Struktur zu haben als die kompilierte Version von CommonJS oben, aber tatsächlich ist das Wesentliche dasselbe. Da sich umd nun um verschiedene Betriebsumgebungen kümmern muss, erweitert es require('jquery') und übergibt es als Parameter der Factory. Für jede Betriebsumgebung hat jede ihren eigenen Ansatz:
CommonJS: Behalten Sie die require('jquery')-Anweisung bei.
AMD: Definieren Sie jquery als abhängiges Modul in define.
Var: Übernehmen Sie die JQuery-Variable aus der globalen Domäne, was erfordert, dass JQuery vor dem Modul geladen wird.
Dann übergeben sie unabhängig von der Situation das geladene JQuery-Modul als Parameter an die Factory-Funktion, damit das Util-Modul korrekt geladen werden kann.
Der obige Teil, der den von Webpack generierten Code betrifft, ist möglicherweise etwas kompliziert. Sie müssen den Mechanismus und das Prinzip des Webpack-Paketierungsmoduls besser verstehen. Ich habe diesen Teil in diesem Artikel ausführlich besprochen.
Zusammenfassung
Oben geht es um die Verwendung der externen Option von Webpack und ihre Funktionsweise wird anhand des kompilierten JS-Codes analysiert. Ich denke, es ist immer noch sehr wichtig, den generierten Code im Zusammenhang mit Webpack zu lesen, damit Sie den externen Mechanismus wirklich verstehen und wissen, wie man debuggt, wenn Sie auf einige Fallstricke stoßen.
Ich habe das Obige für Sie zusammengestellt und hoffe, dass es Ihnen in Zukunft hilfreich sein wird.
Verwandte Artikel:
Beispiel für die Definition Ihrer eigenen Winkelzeitkomponente basierend auf Datepicker
Vue.js weist dem src von img dynamisch einen Wert zu
Das obige ist der detaillierte Inhalt vonSo verwenden Sie ein externes Modul im Webpack. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
