webpack笔记（一）- webpack / webpack的诞生背景

要学习webpack, 我们必须要知道浏览器现在的模块化有什么问题

效率问题

先来看一个例子

我们要做的事情非常简单, 新建一个目录, 在里面在新建src目录, 在目录下创建几个文件分别是: index.html, index.js, a.js, b.js, 目录格式如下

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-caNDMlTJ-1595234792857)(./blogImages/browserModule.png)]

这几个文件对应的文件各自的内容如下

index.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>ES6模块化</title>
</head>
<body>
    <script src="./index.js" type="module"></script>
</body>
</html>

index.js

// index.js
import a from './a.js';

console.log('我是index.js');

a.js

import b from './b.js';

console.log('我是a.js');
export default 'a';

b.js

console.log('我是b.js');

export default 'b';

我们用浏览器( 记得用open with live server )打开index.html, 会看到界面输出如下:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9rwrOi9r-1595234792859)(./blogImages/BrowserResult.png)]

结果并无异样, 我们可以打开network看看。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-s7TSaI5S-1595234792860)(./blogImages/browserNetWork.png)]

这里我们发现请求了一次index.js, 然后又请求了一次a.js和一次b.js, 这就是问题所在, 我们在企业级开发中至少有几百个js, 难道我们要发几百次网络请求吗？这势必会对网络性能造成致命打击, 也是完全没有必要的

所以这里我们引出了浏览器中模块化的第一个问题效率问题

模块化导致JS代码需要不断的被细分, 而精细的模块划分带来了更多的JS文件, 更多的JS文件带来了更多的网络请求, 降低了页面访问效率

兼容性问题和工具问题

目前浏览器仅支持ES6的模块化, 那么意味着我们不能在代码中书写commonjs规范的代码, 更意味着我们在浏览器更加不能用commonjs导出的库和包, 我们知道, 学习了npm, yarn这类包管理工具以后, 我们不会再用很low的方式去引入库或者包, 都会用npm install的方式, 那来吧, 我们试着来看看

npm install jquery -S // 安装一下jQuery

然后我们在index.js中引入jQuery

// index.js
import a from './a.js';
import jQuery from 'jquery';

console.log('我是index.js');

我们看看这样能行吗？

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-v17VZniW-1595234792862)(./blogImages/importJQuery.png)]

浏览器已经给我们报错了, 他说我们必须用./, /, ../这类方式导入模块, 那行, 那我们按照这种方式来引入

import a from './a.js';
import $ from '../node_modules/jquery/dist/jquery.js';

console.log('我是index.js');

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AgSVCTvJ-1595234792863)(./blogImages/jQueryError.png)]

这时候他给我们报了另外一个错误, 说jQuery里没有一个export default, 没错, jQuery就是遵循的commonjs的规范导出的, 所以这种时候, 我们就很难办

上面的现象就给我们引出了第二个问题, 在使用工具时的兼容问题

在默认情况下, 浏览器跟npm的结合问题非常大, 要解决这个问题, 必须使用第三方工具

这些问题也仅仅是前端工程化的一个小缩影

当我们开发一个有规模的程序, 会遇到非常多的非业务问题, 这些问题包括: 执行效率, 兼容性, 代码的可维护性和扩展性, 团队协作和测试等, 我们将这些问题称之为工程问题, 工程问题与业务无关, 但他深刻的影响到开发进度, 如果没有一个好的工具解决这些问题, 将使得开发极其的缓慢, 同时也让开发者陷入技术的泥潭

在浏览器端, 开发环境（development）和线上环境（production）的侧重点完全不一样

开发环境

模块划分越细越好
最好支持多种模块化标准
支持npm和其他包管理器下载的模块
能解决其他工程化的问题

线上环境

文件数量越少越好
文件体积越小越好
代码内容越乱越好
所有浏览器都要兼容
执行效率越高越好

解决方案

既然开发环境和线上环境面临的局面有巨大差异, 因此, 我们需要一个工具, 这个工具能够让开发者专心的书写开发环境的代码, 然后利用这个工具将开发时态编写的代码转化为运行时态所需要的东西

这样的工具, 我们称之为构建工具

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6mcs4OsO-1595234792864)(./blogImages/buildTool.png)]

这样一来, 开发者就只需要专注于开发时态的代码结构, 而不用担心运行的时候遭遇的问题了

常见的构建工具

webpack
grunt
gulp
browserfly
其他

而其中, 生态最繁荣, 也是目前最繁荣的构建工具明叫webpack, 也是我们学习webpack最大的理由