【工程化】webpack 编译后文件解析

webpack 为什么这么神奇? 为什么能把 es6的模块化,node js 的模块化变成能让浏览器支持的代码??

让我们看看一个最简单的bundle文件, 一探究竟

如何实现模块化

webpack 打包后需要把所有模块的代码同步过来, 所以遵守的是commonJs 规范,

2019-09-15-14-21-44

这是一个简简单单的代码,编译后的一个文件, 实际代码如下
2019-09-15-14-23-33

这也证明了 webpack 不管你干了啥都会往你的代码里赛进这么一坨东西。

好的, 现在让我们把代码折叠起来然后删除没用的注释, 先不管细节,看看他的整体脉络
2019-09-15-14-39-09

我们可以看到, 这就是我们最最熟悉的IIFE, 原来神秘的webapck 无非也就是做了一件事, 将现在的模块化转变成为上古时代的模块化。

并且一个个模块, 都已以其文件路径作为key , 具体的业务逻辑作为value , 这里我们就可以清晰的看到, 一个src/index.js 的文件路径后面跟着的一个函数 , 里面就大大的写着

1
eval("console.log(\"你好,webpack\")\n\n//# sourceURL=webpack:///./src/index.js?");

这里顺带一嘴, 这里生成的

1
(\"你好,webpack\")\n

这样字符串就是我们当初玩弄 AST 时,看到的 raw, 也就是带转译的元数据, 当然, 这里如果不实用整个就无法运行了,对吧

为什么是eval

webpack 在 development 模式下产出的就是 eavl , 如果是 production 生产环境模式, 是绝对不会有这样的形式代码

生产环境下的产出:
2019-09-15-14-59-15

那 webapck 为什么会这样选择呢?

  1. 生成eavl 方便开发环境下的热更新
  2. 生产环境不使用 eval 是因为 eval的性能不高,并且不安全, 容易被人XSS
你的支持将鼓励我继续创作