webpack是什么？

内容纲要

WebPack可以看做是模块打包机：它做的事情是，分析你的项目结构，找到JavaScript模块以及其它的一些浏览器不能直接运行的拓展语言（Scss，TypeScript等），并将其打包为合适的格式以供浏览器使用。

今的很多网页其实可以看做是功能丰富的应用，它们拥有着复杂的JavaScript代码和一大堆依赖包。为了简化开发的复杂度，前端社区涌现出了很多好的实践方法

a:模块化，让我们可以把复杂的程序细化为小的文件;

b:类似于TypeScript这种在JavaScript基础上拓展的开发语言：使我们能够实现目前版本的JavaScript不能直接使用的特性，并且之后还能能装换为JavaScript文件使浏览器可以识别；

c:scss，less等CSS预处理器

………

这些改进确实大大的提高了我们的开发效率，但是利用它们开发的文件往往需要进行额外的处理才能让浏览器识别,而手动处理又是非常繁琐的，这就为WebPack类的工具的出现提供了需求。

浏览器在解析js时的盲点

要理解webpack是个什么东西，解决了什么问题，我们首先要理解前段的一个最大的坑，就是浏览器在解析js的时候，它有一个盲点就是，没有做到js文件的模块化。比如一个文件要想给另外一个文件暴露出去一部分数据或者一个变量，那只能将它定义在全局的作用域下，没有其他的办法。

比如b依赖于c，a依赖于b：

<body>
<script src="c.js"></script>
<script src="b.js"></script>
<script src="a.js"></script></body>

这种依赖关系随着项目越来越大、越来越复杂，也会变得复杂，而且依赖链会越来越长。但是最坑的地方每一个依赖里头必须暴露出来一个全局变量。这个就特别难受。

(function(){
window.msg ="abc"})()

新的隐患和解决方案

通过定义全局变量，虽然可以暂时解决依赖的问题，这会带来一个新的隐患。我不知道在什么时候，用什么样的方式会把一个全局变量给覆盖掉，在不知情的情况下。如果所有的依赖都是我们自己写的，那还好，可能我们都清楚我们定义了哪些全局变量，那如果引入的是外部的库，那这个全局变量就不受我们的控制了，因为人家的库也随时可能更新的，可能后面又变了。那很难去绕开这个东西。所以无论用任何方式来定义全局变量，总有一定的可能性发生冲突。这样就特别不踏实，而且还没有什么办法。

后面出现了一个node，nodejs可以直接跑在操作系统上。虽然浏览器也能跑在系统上，但是nodejs有个非常好的机制，就是在node的眼里，所有的文件都是一个模块，任何一个模块都可以有两个口，一个是入水口、一个是出水口,这样一来每个文件只需要管好两个，一个入水口一个出水口。这个就是node里面有个module，其中module.exports表示出水口，module.require表示依赖，表示入水口。

//b.js出水口
var msg ="asd";
module.exports ={mes:mes}

//a.js入水口
var msg = require(./b.js).msg;//可以省略.js 如：require(./b).msg

require(./b.js).msg明确指明我要用b文件里面的msg，exports 指明了我要导出去的变量。再也不需要全局变量这样的东西。

webpack它解决的最重要的问题就是这样一个问题，我们用写后端语言的方式写前端的代码，webpack可以做到动态的把后端的代码变成浏览器能够读懂的代码。即把后端代码前端化。这是最主要的。

至于它打包出来的文件有多丑我们不管，只要它能用，只要它体积小就可以了。

webpack a.js bundle.js

这样一来，我们即做到用后端的方式让我们的代码更加模块化，也能然浏览器来读懂我们的代码。

这里主要是理解，webpack是什么，为什么要搞得怎么复杂。历史包袱太重，欠的账太多了，一开始没考虑的东西太多了。

Post Views: 139