webpack模塊化的原理解析
commonjs
在webpack中既可以書寫commonjs模塊也可以書寫es模塊,而且不用考慮瀏覽器的兼容性問題,我們來分析一下原理。
首先搞清楚commonjs模塊化的處理方式,簡單配置一下webpack,寫兩個模塊編譯一下看一下:
webpack.config.js
module.exports = { mode: "development", devtool: "none" }
index.js
const a = require('./a') console.log(a)
a.js
const a = 'a'; module.exports = a;
編譯結果
查看編譯結果,可以發現webpack對於每個模塊的做法類似於node,將每個模塊放在一個函數環境中並向其中傳入一些必要的參數。webpack將這些模塊組成一個對象(屬性名是模塊路徑(模塊id),屬性值為模塊內容)傳入一個立即執行函數,立即執行函數中定義瞭一個函數 __webpack_require__
類似node中的require
函數,實現瞭導入模塊的作用。
打包結果中刪去瞭一些註釋和暫時用不要的代碼,可以很明顯的看出來實現commonjs模塊化的關鍵就是這個 __webpack_require__
函數,通過傳入模塊id來得到模塊的導出。
require 函數
__webpack_require__
函數的實現:
function __webpack_require__(moduleId) { // Check if module is in cache if (installedModules[moduleId]) { return installedModules[moduleId].exports; } // Create a new module (and put it into the cache) var module = installedModules[moduleId] = { i: moduleId, l: false, exports: {} }; // Execute the module function modules[moduleId].call(module.exports, module, module.exports, __webpack_require__); // Flag the module as loaded module.l = true; // Return the exports of the module return module.exports; }
如果熟悉node就很容易理解這個函數瞭:
- 首先查看這個模塊是否已經被加載過,所以就需要一個全局變量
installedModules
用來記錄所有被加載過模塊的導出 - 沒有加載過的模塊就先構造一個
module
對象,關鍵是要有一個exports
屬性 - 執行模塊代碼並返回模塊導出值
最終的一步就是需要加載啟動模塊,也就是IIFE的最後一句:
return __webpack_require__("./src/index.js");
ES Module
es 模塊化的處理方式是需要借助 __webpack_require__
實現的,首先看一些剛才被刪除的代碼:
__webpack_require__.r
該函數用於標識es模塊的導出
// define __esModule on exports __webpack_require__.r = function (exports) { if (typeof Symbol !== 'undefined' && Symbol.toStringTag) { Object.defineProperty(exports, Symbol.toStringTag, { value: 'Module' }); } Object.defineProperty(exports, '__esModule', { value: true }); };
__webpack_require__.d
用於處理es模塊的具名導出
// define getter function for harmony exports __webpack_require__.d = function (exports, name, getter) { if (!__webpack_require__.o(exports, name)) { Object.defineProperty(exports, name, { enumerable: true, get: getter }); } };
__webpack_require__.o
就是給 hasOwnPreperty
換瞭個名字
__webpack_require__.o = function (object, property) { return Object.prototype.hasOwnProperty.call(object, property); };
我們改一下模塊代碼看看純es Module導入導出的編譯結果:
index.js
import a, { test } from './a' import b from './b' console.log(a); test(); console.log(b)
a.js
const a = 'a'; function test() { } export default a; export { test }
b.js
const b = 'b'; export default b;
參考資料 前端進階面試題詳細解答
編譯結果
{ "./src/a.js": (function (module, __webpack_exports__, __webpack_require__) { "use strict"; __webpack_require__.r(__webpack_exports__); /* harmony export (binding) */ __webpack_require__.d(__webpack_exports__, "test", function () { return test; }); const a = 'a'; function test() { } /* harmony default export */ __webpack_exports__["default"] = (a); }), "./src/b.js": (function (module, __webpack_exports__, __webpack_require__) { "use strict"; __webpack_require__.r(__webpack_exports__); const b = 'b'; /* harmony default export */ __webpack_exports__["default"] = (b); }), "./src/index.js": (function (module, __webpack_exports__, __webpack_require__) { "use strict"; __webpack_require__.r(__webpack_exports__); /* harmony import */ var _a__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__("./src/a.js"); /* harmony import */ var _b__WEBPACK_IMPORTED_MODULE_1__ = __webpack_require__("./src/b.js"); console.log(_a__WEBPACK_IMPORTED_MODULE_0__["default"]) Object(_a__WEBPACK_IMPORTED_MODULE_0__["test"])(); console.log(_b__WEBPACK_IMPORTED_MODULE_1__["default"]) }) }
根據編譯結果可以很明白的看出來,和 commonjs 編譯出來的結果差不多,核心都是使用 __webpack_require__
函數,區別在於es模塊化,exports
對象首先就會被__webpack_require__.r
標記為es module,對於默認導出就是 exports
的 default
屬性,對於具名導出使用 __webpack_require__.d
包裝瞭一下,目的是讓這些具名導出在模塊之外隻能讀不能被修改(這是es module的特點)。
v5 的變化
但是為什麼 default
沒有被__webpack_require__.d
處理,這不合理啊。本來是使用的 webpack 4打包的,然後換瞭webpack 5試瞭一下,webpack 5打包的結果中 default
也被處理瞭,這可能是webpack 4的一個小bug吧。
webpack5的編譯結果有些許的不同,但是整個邏輯是沒有變的:
兩種模塊化交互
webpack 是支持兩種模塊化代碼共存的,雖然不建議這樣做。首先我們先看一下他們互相導入的時候的導入結果是什麼樣的:
我們來看看 webpack 是如何實現的,先修改一下模塊:
index.js
const { a, test } = require('./a')
a.js
import b from './b' import * as bbb from './b' console.log(bbb) console.log(b) console.log(b.b) const a = 'a'; function test() { } export default a; export { test };
b.js
module.exports = { b: () => { }, moduleName: 'b' }
編譯結果
{ "./src/a.js": (function (module, __webpack_exports__, __webpack_require__) { "use strict"; __webpack_require__.r(__webpack_exports__); /* harmony export (binding) */ __webpack_require__.d(__webpack_exports__, "test", function () { return test; }); /* harmony import */ var _b__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__("./src/b.js"); /* harmony import */ var _b__WEBPACK_IMPORTED_MODULE_0___default = __webpack_require__.n(_b__WEBPACK_IMPORTED_MODULE_0__); console.log(_b__WEBPACK_IMPORTED_MODULE_0__) console.log(_b__WEBPACK_IMPORTED_MODULE_0___default.a) console.log(_b__WEBPACK_IMPORTED_MODULE_0___default.a.b) const a = 'a'; function test() { } /* harmony default export */ __webpack_exports__["default"] = (a); }), "./src/b.js": (function (module, exports) { module.exports = { b: () => { }, moduleName: 'b' } }), "./src/index.js": (function (module, exports, __webpack_require__) { const { a, test } = __webpack_require__("./src/a.js") }) }
可以發現當通過es模塊的方式去 import
一個commonjs模塊時,就會把導入的模塊進行一層包裝,通過 __webpack_require__.n
,主要目的應該是為瞭兼容 import * as obj from '....'
這樣的語法。
該函數的具體實現:
__webpack_require__.n = function (module) { var getter = module && module.__esModule ? function getDefault() { return module['default']; } : function getModuleExports() { return module; }; __webpack_require__.d(getter, 'a', getter); return getter; }
總結
webpack 中實現模塊化的核心就是 __webpack_require__
函數,無論是commonjs模塊化還是es 模塊都是通過該函數來導入的。並且利用立即執行函數的特點實現瞭作用域的封閉避免瞭全局變量的污染,非常的巧妙。
到此這篇關於webpack模塊化的原理的文章就介紹到這瞭,更多相關webpack模塊化內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!
推薦閱讀:
- webpack cjs運行時分析示例詳解
- Js模塊打包exports require import的用法和區別
- webpack output.library的16 種取值方法示例
- JS中ESModule和commonjs介紹及使用區別
- 淺談Webpack是如何打包CommonJS的