Heim >Web-Frontend >js-Tutorial >Eine ausführliche Erläuterung der Grundprinzipien von Webpack-Modulen
In diesem Artikel wird hauptsächlich das Prinzip des Webpack-Organisationsmoduls vorgestellt. Jetzt teile ich es mit Ihnen und gebe Ihnen eine Referenz.
Es ist mittlerweile Mainstream, Webpack zum Packen von JS und anderen Dateien im Front-End zu verwenden. In Verbindung mit der Popularität von Node ähnelt die Front-End-Engineering-Methode immer mehr der Back-End-Methode. Am Ende wird alles modularisiert und zusammengefügt. Aufgrund der ständigen Updates der Webpack-Versionen und verschiedener komplizierter Konfigurationsmöglichkeiten kommt es bei der Nutzung zu einigen mysteriösen Fehlern, die oft für Verwirrung sorgen. Daher ist es sehr hilfreich zu verstehen, wie Webpack kompilierte Module organisiert und wie der generierte Code ausgeführt wird, da es sich sonst immer um eine Black Box handelt. Natürlich bin ich ein Front-End-Neuling und habe vor kurzem erst begonnen, die Prinzipien von Webpack zu studieren, daher werde ich hier einige Notizen machen.
Kompilierungsmodul
Das Wort „kompilieren“ klingt sehr hochtechnologisch, und der generierte Code ist oft ein großes Durcheinander unverständlicher Dinge, daher ist er oft entmutigend , aber die Grundprinzipien sind eigentlich überhaupt nicht schwierig. Bei der sogenannten Kompilierung von Webpack handelt es sich eigentlich nur darum, dass Webpack Ihren Quellcode analysiert, bestimmte Änderungen daran vornimmt und dann den gesamten Quellcode in einer Datei organisiert. Abschließend wird eine große Bundle-JS-Datei generiert, die vom Browser oder einer anderen Javascript-Engine ausgeführt wird und das Ergebnis zurückgibt.
Hier ist ein einfacher Fall, um das Prinzip des Webpack-Verpackungsmoduls zu veranschaulichen. Zum Beispiel haben wir ein Modul mA.js
var aa = 1;
function getDate() {
return new Date();
}
module.exports = {
aa: aa,
getDate: getDate
}Ich habe beiläufig eine Variable aa und eine Funktion getDate definiert und sie dann mit CommonJS exportiert.
Dann definieren Sie eine app.js als Hauptdatei, immer noch im CommonJS-Stil:
var mA = require('./mA.js'); console.log('mA.aa =' + mA.aa); mA.getDate();
Jetzt haben wir zwei Module, gepackt mit Webpack, die Eintragsdatei ist app.js, Abhängig von Das Modul mA.js, Webpack muss mehrere Dinge tun:
Analysieren Sie ausgehend vom Einstiegsmodul app.js die Abhängigkeiten aller Module und lesen Sie alle verwendeten Module.
Der Quellcode jedes Moduls wird in einer Funktion organisiert, die sofort ausgeführt wird.
Schreiben Sie die Syntax für „require“ und „export“ im Modulcode sowie die entsprechenden Referenzvariablen neu.
Etablieren Sie in der endgültig generierten Bundle-Datei ein Modulverwaltungssystem, das die verwendeten Module zur Laufzeit dynamisch laden kann.
Wir können uns das obige Beispiel ansehen, das Ergebnis der Webpack-Verpackung. Die endgültige Bundle-Datei ist im Allgemeinen eine große Funktion, die sofort ausgeführt wird. Die Organisationsebene ist relativ komplex und viele Namen sind relativ unklar. Daher habe ich hier einige Umschreibungen und Änderungen vorgenommen, um sie so einfach und verständlich wie möglich zu gestalten möglich.
Listen Sie zunächst alle verwendeten Module auf und verwenden Sie deren Dateinamen (normalerweise vollständige Pfade) als IDs, um eine Tabelle zu erstellen:
var modules = {
'./mA.js': generated_mA,
'./app.js': generated_app
}Der Schlüssel ist, dass das oben generierte_xxx Was ist? Es handelt sich um eine Funktion, die den Quellcode jedes Moduls einschließt, ihn zu einem lokalen Bereich macht, sodass interne Variablen nicht offengelegt werden, und jedes Modul tatsächlich in eine Ausführungsfunktion umwandelt. Die Definition lautet im Allgemeinen wie folgt:
function generated_module(module, exports, webpack_require) {
// 模块的具体代码。
// ...
}Der spezifische Code des Moduls bezieht sich hier auf den generierten Code, den Webpack als generierten Code bezeichnet. Beispielsweise erhält mA nach dem Umschreiben dieses Ergebnis:
function generated_mA(module, exports, webpack_require) {
var aa = 1;
function getDate() {
return new Date();
}
module.exports = {
aa: aa,
getDate: getDate
}
}Auf den ersten Blick scheint es genau das Gleiche wie der Quellcode zu sein. Tatsächlich erfordert oder importiert mA keine anderen Module, und der Export verwendet auch den traditionellen CommonJS-Stil, sodass keine Änderungen am generierten Code vorgenommen werden. Es ist jedoch erwähnenswert, dass das letzte module.exports = ... das Modul hier das von außen übergebene Parametermodul ist, was uns tatsächlich sagt, dass beim Ausführen dieser Funktion der Quellcode des Moduls mA ausgeführt wird , und schließlich Der zu exportierende Inhalt wird extern gespeichert. Dies markiert den Abschluss des mA-Ladens, und die externe Sache ist eigentlich das Modulverwaltungssystem, das später besprochen wird.
Schauen Sie sich als nächstes den generierten Code von app.js an:
function generated_app(module, exports, webpack_require) {
var mA_imported_module = webpack_require('./mA.js');
console.log('mA.aa =' + mA_imported_module['aa']);
mA_imported_module['getDate']();
}Sie können sehen, dass der Quellcode von app.js im Teil über das eingeführte Modul mA geändert wurde, weil weder das eine noch das andere require/ Exports oder Import/Export im ES6-Stil können nicht direkt vom JavaScript-Interpreter ausgeführt werden. Sie müssen sich auf das Modulverwaltungssystem verlassen, um diese abstrakten Schlüsselwörter zu konkretisieren. Mit anderen Worten, webpack_require ist die spezifische Implementierung von require, die das Modul mA dynamisch laden und das Ergebnis an die App zurückgeben kann.
An diesem Punkt haben Sie möglicherweise nach und nach die Idee eines Modulverwaltungssystems in Ihrem Kopf entwickelt. Werfen wir einen Blick auf die Implementierung von webpack_require:
// 加载完毕的所有模块。
var installedModules = {};
function webpack_require(moduleId) {
// 如果模块已经加载过了，直接从Cache中读取。
if (installedModules[moduleId]) {
return installedModules[moduleId].exports;
}
// 创建新模块并添加到installedModules。
var module = installedModules[moduleId] = {
id: moduleId,
exports: {}
};
// 加载模块，即运行模块的生成代码，
modules[moduleId].call(
module.exports, module, module.exports, webpack_require);
return module.exports;
}Beachten Sie, dass die Module im Der vorletzte Satz ist der generierte Code aller zuvor definierten Module:
var modules = {
'./mA.js': generated_mA,
'./app.js': generated_app
}Die Logik von webpack_require ist sehr klar geschrieben. Überprüfen Sie zunächst, ob das Modul geladen wurde. Wenn ja, geben Sie das Exportergebnis des Moduls direkt zurück aus dem Cache. Wenn es sich um ein brandneues Modul handelt, erstellen Sie das entsprechende Datenstrukturmodul und führen Sie den generierten Code dieses Moduls aus. Diese Funktion übergibt das von uns erstellte Modulobjekt und sein Exportfeld. Dies sind tatsächlich die Export- und Exportfelder in CommonJS . Der Ursprung des Moduls. Nach Ausführung dieser Funktion wird das Modul geladen und die zu exportierenden Ergebnisse werden im Modulobjekt gespeichert.
所以我们看到所谓的模块管理系统，原理其实非常简单，只要耐心将它们抽丝剥茧理清楚了，根本没有什么深奥的东西，就是由这三个部分组成：
// 所有模块的生成代码 var modules； // 所有已经加载的模块，作为缓存表 var installedModules； // 加载模块的函数 function webpack_require(moduleId);
当然以上一切代码，在整个编译后的bundle文件中，都被包在一个大的立即执行的匿名函数中，最后返回的就是这么一句话：
return webpack_require(‘./app.js');
即加载入口模块app.js，后面所有的依赖都会动态地、递归地在runtime加载。当然Webpack真正生成的代码略有不同，它在结构上大致是这样：
(function(modules) {
var installedModules = {};
function webpack_require(moduleId) {
// ...
}
return webpack_require('./app.js');
}) ({
'./mA.js': generated_mA,
'./app.js': generated_app
});可以看到它是直接把modules作为立即执行函数的参数传进去的而不是另外定义的，当然这和上面的写法没什么本质不同，我做这样的改写是为了解释起来更清楚。
ES6的import和export
以上的例子里都是用传统的CommonJS的写法，现在更通用的ES6风格是用import和export关键词，在使用上也略有一些不同。不过对于Webpack或者其它模块管理系统而言，这些新特性应该只被视为语法糖，它们本质上还是和require/exports一样的，例如export：
export aa // 等价于: module.exports['aa'] = aa export default bb // 等价于: module.exports['default'] = bb
而对于import：
import {aa} from './mA.js'
// 等价于
var aa = require('./mA.js')['aa']比较特殊的是这样的：
import m from './m.js'
情况会稍微复杂一点，它需要载入模块m的default export，而模块m可能并非是由ES6的export来写的，也可能根本没有export default，所以Webpack在为模块生成generated code的时候，会判断它是不是ES6风格的export，例如我们定义模块mB.js:
let x = 3;
let printX = () => {
console.log('x = ' + x);
}
export {printX}
export default x它使用了ES6的export，那么Webpack在mB的generated code就会加上一句话：
function generated_mB(module, exports, webpack_require) {
Object.defineProperty(module.exports, '__esModule', {value: true});
// mB的具体代码
// ....
}也就是说，它给mB的export标注了一个__esModule，说明它是ES6风格的export。这样在其它模块中，当一个依赖模块以类似import m from './m.js'这样的方式加载时，会首先判断得到的是不是一个ES6 export出来的模块。如果是，则返回它的default，如果不是，则返回整个export对象。例如上面的mA是传统CommonJS的，mB是ES6风格的：
// mA is CommonJS module import mA from './mA.js' console.log(mA); // mB is ES6 module import mB from './mB.js' console.log(mB);
我们定义get_export_default函数：
function get_export_default(module) {
return module && module.__esModule? module['default'] : module;
}这样generated code运行后在mA和mB上会得到不同的结果：
var mA_imported_module = webpack_require('./mA.js'); // 打印完整的 mA_imported_module console.log(get_export_default(mA_imported_module)); var mB_imported_module = webpack_require('./mB.js'); // 打印 mB_imported_module['default'] console.log(get_export_default(mB_imported_module));
这就是在ES6的import上，Webpack需要做一些特殊处理的地方。不过总体而言，ES6的import/export在本质上和CommonJS没有区别，而且Webpack最后生成的generated code也还是基于CommonJS的module/exports这一套机制来实现模块的加载的。
模块管理系统
以上就是Webpack如何打包组织模块，实现runtime模块加载的解读，其实它的原理并不难，核心的思想就是建立模块的管理系统，而这样的做法也是具有普遍性的，如果你读过Node.js的Module部分的源代码，就会发现其实用的是类似的方法。这里有一篇文章可以参考。
上面是我整理给大家的，希望今后会对大家有帮助。
相关文章：
Das obige ist der detaillierte Inhalt vonEine ausführliche Erläuterung der Grundprinzipien von Webpack-Modulen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!