webpack究竟干了什么（一）

秒速五厘米 2024-04-17 05:34 50阅读 0赞

今时今日，做前端不用个webpack好像都被时代抛弃了一样，每天开发的时候npm run dev，该上线了npm run build，反正执行个命令刷刷地就打包好了，你根本无需知道执行命令之后整个过程究竟干了什么。webpack就像个黑盒，你得小心翼翼遵循它的配置行事，配好了就万幸。这使得我很长一段时间以来，都对webpack毕恭毕敬，能跑起来的代码就是最好的代码，千万别乱动配置。  
终于有一天，我忍不住要搞清楚webpack究竟做了什么。

## 我们为什么需要webpack ##

去搞清楚webpack做了什么之前，我觉得首先要思考一下我们为什么需要webpack，它究竟解决了什么痛点。想想我们日常搬砖的场景：  
1.开发的时候需要一个开发环境，要是我们修改一下代码保存之后浏览器就自动展现最新的代码那就好了（热更新服务）  
2.本地写代码的时候，要是调后端的接口不跨域就好了（代理服务）  
3.为了跟上时代，要是能用上什么ES678N等等新东西就好了（翻译服务）  
4.项目要上线了，要是能一键压缩代码啊图片什么的就好了（压缩打包服务）  
5.我们平时的静态资源都是放到CDN上的，要是能自动帮我把这些搞好的静态资源怼到CDN去就好了（自动上传服务）  
巴拉巴拉等等服务，那么多你需要的服务，如果你打一个响指，这些服务都有条不紊地执行好，岂不是美滋滋！所以我们需要webpack帮我们去整合那么多服务，而node的出现，赋予了我们去操作系统的能力，这才有了我们今天的幸福（kubi）生活(manong)。  
所以我觉得要根据自己的需求来使用webpack，知道自己需要什么样的服务，webpack能不能提供这样的服务，如果可以，那么这个服务应该在构建中的哪个环节被处理。

*  如果与输入相关的需求，找entry（比如多页面就有多个入口）
 *  如果与输出相关的需求，找output（比如你需要定义输出文件的路径、名字等等）
 *  如果与模块寻址相关的需求，找resolve（比如定义别名alias）
 *  如果与转译相关的需求，找loader（比如处理sass处理es678N）
 *  如果与构建流程相关的需求，找plugin（比如我需要在打包完成后，将打包好的文件复制到某个目录，然后提交到git上）

抽丝剥茧之后，去理解这些的流程，你就能从webpack那一坨坨的配置中，定位到你需求被webpack处理的位置，最后加上相应的配置即可。

## webpack打包出来的什么 ##

webpack搞了很多东西，但最终产出的无非就是经过重重服务处理过的代码，那么这些代码是怎样的呢？  
首先我们先来看看入口文件index.js：

console.log('index')
    const one = require('./module/one.js')
    const two = require('./module/two.js')
    one()
    two()

嗯，很简单，没什么特别，引入了两个模块，最后执行了它们一下。其中one.js和two.js的代码也很简单，就是导出了个函数：

// one.js module.exports = function () { console.log('one') }

// two.js module.exports = function () { console.log('two') }

好了，就是这么简单的代码，放到webpack打包出来的是什么呢？

console.log(‘index’)  
const one = **webpack\_require**(1)  
const two = **webpack\_require**(2)  
one()  
two()

/\*\**/ \}),  
/* 1 */  
/*\*\*/ (function(module, exports) \{

module.exports = function () \{  
console.log(‘one’)  
\}

/\*\**/ \}),  
/* 2 */  
/*\*\*/ (function(module, exports) \{

module.exports = function () \{  
console.log(‘two’)  
\}

/\*\*\*/ \})  
/\*\*\*\*\*\*/ \]);" title="" data-original-title=“复制”>

/******/ (function(modules) { // webpackBootstrap /******/ // The module cache /******/ var installedModules = {}; /******/ /******/ // The require function /******/ 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; /******/ } /******/ /******/ /******/ // expose the modules object (webpack_modules) /******/ webpack_require.m = modules; /******/ /******/ // expose the module cache /******/ webpack_require.c = installedModules; /******/ /******/ // define getter function for harmony exports /******/ webpack_require.d = function(exports, name, getter) { /******/ if(!webpack_require.o(exports, name)) { /******/ Object.defineProperty(exports, name, { /******/ configurable: false, /******/ enumerable: true, /******/ get: getter /******/ }); /******/ } /******/ }; /******/ /******/ // getDefaultExport function for compatibility with non-harmony modules /******/ 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; /******/ }; /******/ /******/ // Object.prototype.hasOwnProperty.call /******/ webpack_require.o = function(object, property) { return Object.prototype.hasOwnProperty.call(object, property); }; /******/ /******/ // webpack_public_path /******/ webpack_require.p = “”; /******/ /******/ // Load entry module and return exports /******/ return webpack_require(webpack_require.s = 0); /******/ }) /************************************************************************/ /*****/ ([ / 0 / /**/ (function(module, exports, webpack_require) {

console.log(‘index’)  
const one = **webpack\_require**(1)  
const two = **webpack\_require**(2)  
one()  
two()

/\*\**/* \}),  
/ 1 */*  
/\*\*/ (function(module, exports) \{

module.exports = function () \{  
console.log(‘one’)  
\}

/\*\**/* \}),  
/ 2 */*  
/\*\*/ (function(module, exports) \{

module.exports = function () \{  
console.log(‘two’)  
\}

/\*\*\*/ \})  
/\*\*\*\*\*\*/ \]);

真是不忍直视……我写得这么简洁优雅的代码，经过webpack的处理后如此不堪入目！但为了搞清楚这坨东西究竟做了什么，我不得不忍丑去将它简化了一下。

## 简化webpack打包出来的代码 ##

其实进过简化后就可以看到，这些代码意图十分明显，也是我们十分熟悉的套路。

(function (modules) { const require = function (moduleId) { const module = {} module.exports = null modules[moduleId].call(module, module, require) return module.exports } require(0) })([ function (module, require) { console.log('index') const one = require(1) const two = require(2) one() two() }, function (module, require) { module.exports = function () { console.log('one') } }, function (module, require) { module.exports = function () { console.log('two') } }])

这样看可能会直观一点：  
![clipboard.png][]  
你会看到这不就是我们挂在嘴边的自执行函数吗？然后参数是一个数组，这个数组就是我们的模块，当require(0)的时候就会执行这个数组索引为0的代码，以此类推而达到模块化的效果。这里有个关键点，就是我们明明写的时候是require('./module/one.js')，怎么最后出来可以变成require(1)呢？

## 让我们自己来撸一个 ##

没有什么比自己撸一个理解得更透彻了。我们根据上面的最终打包的结果来捋一捋要做一些什么事情。  
1.观察一下，我们需要一个自执行函数，这里面需要控制的是这个自执行函数的传参，就是那个数组  
2.这个数组是毋容置疑是根据依赖关系来形成的  
3.我们要找到所有的require然后将require的路径替换成对应数组的索引  
4.将这个处理好的文件输出出来  
ok，上代码：

这里的关键是将入口源码转成ast从而分析出require的路径在源码字符串中所在的位置，我们这里用到了esprima去将源码转成ast，然后用estraverse去遍历ast从而筛选出我们感兴趣的节点，这时我们就可以对转化成ast的代码为所欲为了，babel就是这样的原理为我们转化代码的。

## 最后 ##

到这里我们可以知道，除去其他杂七杂八的服务，webpack本质上就是一个将我们平时写的模块化代码转成现在浏览器可以直接执行的代码。当然上面的代码是非常简陋的，我们没有去递归处理依赖，没有去处理require的寻址（比如require('vue')是怎样找到vue在哪里的）等等的细节处理，只为还原一个最简单易懂的结构。上面的源码可以在[这里找到][Link 1]。

[clipboard.png]: 
[Link 1]: https://github.com/febugcoder/learn-webpack