webpack4【guides说明1】

以下内容基本上来自于webpack官网，自己这里只做了下手打，稍微加上自己的理解

附上链接 https://webpack.js.org/guides/

可以看到guide部分有这么多小节：

【1】.getting started

1.创建测试用的目录guides,进入guides目录，npm init, npm install  --save-dev webpack webpack-cli

项目中已安装好webpack了，接下来项目创建一个测试用的js文件 src/index.js,以及index.html文件，项目目录结构至此如下

上述文件只是用来做对比用的，也是我们在没有使用webpack打包项目时的通常做法，使用lodash前，先引入lodash脚本，关注点放在“使用前先引入”上，问题来了，

1.如果项目使用多个 第三方模块，就得前置很多script来引入脚本，

2.如果多个第三方模块之前还存在着依赖，这又得开发人员自己手动去排布scirpt引入顺序

3.多个模块之前如果存在重合的代码部分，这增加了页面初始时的数据传输量，而这通常意味着更多的运营成本，页面响应时间，等等问题

类似webpack这样的工具，就是用来处理这部分问题的。

 

让我们来看看原文是怎么说明上述目录文件的潜在问题的

“在这个例子中，scripts标签间有一个不直接的依赖关系，就是index.js文件依赖于lodash，lodash得先于自己（index.js文件）被加载进来。index.js文件没有显示地申明自己依赖于lodash，它仅仅是假设全局标量_存在。”

“这样带来的管理js项目的问题：

1.没有明显的方式表示，脚本依赖于外部

2.如果一个依赖不可访问了，或者丢失了，又或者引入顺序错误，项目就不能正常工作了

3.如果一个依赖被引入了，但是项目中却没有使用，浏览器还是会下载这些无用的脚本

”

 

这时我们引入webpack来解决上述问题，以及其他问题 

在这之前先稍微改变一下目录结构，该表后的目录如下（改动：创建一个dist目录，并在dist目录下放置前文创建的index.html文件）

注意到+号开头的是 与前文相比增加的行，-号代表与前文对比删掉的行

先不论dist目录干什么用的，main.js哪里来的，单从现在书写的角度看待，index.js文件，我们清楚明了的说明了自己的依赖

lodash(import .....),index.html文件也只是仅仅引入一个脚本文件（也不一定webpack打包后只会产生一个文件，//todo）

 

在本样例设定中，index.js文件清晰的声明了自己需要lodash，并且将其绑定到_,而且这种绑定不会带带来全局命名污染的问题。通过这样的一种 “模块声明自己需要什么依赖”的方式，webpack用这些信息，综合起来创建一个内部用的 “依赖图”，接着用这个图去生成一个优化后的“包”（文件）

 

接着上面的文件设置，就是所谓的打包操作了，运行npx webpack命令（这需要你的Node版本在8.2，npm5.2及其以上版本），不然你就得老老实实的运行 冗余的 “./node_modules/.bin/webpack” 命令，可以看见npx的命令其实就是 简化运行项目本地命令的一种快捷方式。

那么这样打包后，会自动在dist/目录下生成一个main.js文件了，这也就是前面看见index.html中为什么会莫名其妙的直接引入一个main.js文件的原因：webpack再没有使用配置文件的情况下，自动在项目中生成一个dist目录，并在其下生成打包文件main.js。

 

来看看我这边发生了什么 运行npx webpack后，提示了一个错误：Module not found: Error: Can't resolve 'lodash' in 'C:\Users\89434\Desktop\guides\src'，模块lodash没发现

接下来去安装lodash就好了

打包成功，黄色的那段提示暂时不用管它。让我们看看所谓产生的打包文件到底什么样：

可以看见打包后的文件，在使用npx webpack的情况下，内容是被丑化出处理了的

 

点击index.html,正常显示出