Vue全家桶(四):ES6模块化和webpack打包

🔥Vue全家桶🔥

ES6模块化和webpack打包

✍目录总览：

模块化相关规范

1. 模块化概述

传统开发模式的主要问题

① 命名冲突

② 文件依赖

通过模块化解决上述问题

• 模块化就是把单独的一个功能封装到一个模块（文件）中，模块之间相互隔离，但是可以通过特定的接口公开内部成员，也可以依赖别的模块
• 模块化开发的好处：方便代码的重用，从而提升开发效率，并且方便后期的维护

2. 浏览器端模块化规范

3. 服务器端模块化规范

1. CommonJS

① 模块分为 单文件模块 与 包

② 模块成员导出：module.exports 和 exports

③ 模块成员导入：require(‘模块标识符’)

4. 大一统的模块化规范 – ES6模块化

1. 在 ES6 模块化规范诞生之前，Javascript 社区已经尝试并提出了 AMD、CMD、CommonJS 等模块化规范。
2. 但是，这些社区提出的模块化标准，还是存在一定的差异性与局限性、并不是浏览器与服务器通用的模块化标准，例如：
   • AMD 和 CMD 适用于浏览器端的 Javascript 模块化
   • CommonJS 适用于服务器端的 Javascript 模块化
3. 因此，ES6 语法规范中，在语言层面上定义了 ES6 模块化规范，是浏览器端与服务器端通用的模块化开发规范。

ES6模块化规范中定义：

• 每个 js 文件都是一个独立的模块
• 导入模块成员使用 import 关键字
• 暴露模块成员使用 export 关键字

4.1 Node.js 中通过 babel 体验 ES6 模块化

① npm install --save-dev @babel/core @babel/cli @babel/preset-env @babel/node

② npm install --save @babel/polyfill

③ 项目跟目录创建文件 babel.config.js

④ babel.config.js 文件内容如右侧代码

⑤ 通过 npx babel-node index.js 执行代码

const presets = [
	 ["@babel/env", {
 		targets: {
 		edge: "17",
 		firefox: "60",
 		chrome: "67",
 		safari: "11.1"
		}
 	 }]
 ];
 module.exports = { presets };

5. ES6 模块化的基本语法

5.1 默认导出 与 默认导入

• 默认导出语法 export default 默认导出的成员

// 当前文件模块为 m1.js
// 定义私有成员 a 和 c
let a = 10
let c = 20
// 外界访问不到变量 d ,因为它没有被暴露出去
let d = 30
function show() {}
// 将本模块中的私有成员暴露出去，供其它模块使用
export default {
 		a,
 		c,
 		show
}

• 默认导入语法 import 接收名称 from ‘模块标识符’

// 导入模块成员
import m1 from './m1.js'
console.log(m1)
// 打印输出的结果为：
// { a: 10, c: 20, show: [Function: show] }

注意：每个模块中，只允许使用唯一的一次 export default，否则会报错！

5.2 按需导出 与 按需导入

• 按需导出语法 export let s1 = 10

// 当前文件模块为 m1.js
// 向外按需导出变量 s1
export let s1 = 'aaa' 
// 向外按需导出变量 s2
export let s2 = 'ccc'
// 向外按需导出方法 say
export function say = function() {}

• 按需导入语法 import { s1 } from ‘模块标识符’

// 导入模块成员
import { s1, s2 as ss2, say } from './m1.js'
console.log(s1) // 打印输出 aaa
console.log(ss2) // 打印输出 ccc
console.log(say) // 打印输出 [Function: say]

注意：每个模块中，可以使用多次按需导出

5.3 直接导入并执行模块代码

有时候，我们只想单纯执行某个模块中的代码，并不需要得到模块中向外暴露的成员，此时，可以直接导入并执行模块代码。

webpack打包（很重要）

问题的产生

浏览器环境中模块化开发的问题：

• 效率问题：模块化导致JS代码需要不断的被细分, 而精细的模块划分带来了更多的JS文件, 更多的JS文件带来了更多的网络请求, 降低了页面访问效率
• 兼容性问题：
  1. 浏览器不识别ES6（或者更高版本的JS语法）语法，或者CSS预编译处理器（如less，scss）
  2. 目前浏览器仅支持ES6的模块化, 那么意味着我们不能在代码中书写commonjs规范的代码, 更意味着我们在浏览器更加不能用commonjs导出的库和包, 我们知道, 学习了npm, yarn这类包管理工具以后, 我们不会再用很low的方式去引入库或者包, 都会用npm install的方式。
• 使用工具的兼容问题：在默认情况下, 浏览器跟npm的结合问题非常大, 要解决这个问题, 必须使用第三方工具。
• 代码环境问题：浏览器端, 开发环境（development）和线上环境（production）的侧重点完全不同：
  • 开发环境
    1. 模块划分越细越好
    2. 最好支持多种模块化标准
    3. 支持npm和其他包管理器下载的模块
    4. 能解决其他工程化的问题
  • 线上环境（代码上线后）
    1. 文件数量越少越好
    2. 文件体积越小越好
    3. 代码内容越乱越好
    4. 所有浏览器都要兼容
    5. 执行效率越高越好

问题的解决

什么是构建工具？

• 能够让开发者专心的书写开发环境的代码, 然后利用这个工具将开发时态编写的代码转化为运行时态的工具。

• 常见的构建工具：webpack、grunt、gulp、browserfly等等。

• 其中webpack是目前生态最繁荣构建工具。

• 所有资源文件(js/json/css/img/less/…)都会被webpack作为模块处理。

一、webpack概述

• webpack 是一个流行的前端项目构建工具（打包工具），可以解决当前 web 开发中所面临的困境。
• webpack 提供了友好的模块化支持，以及代码压缩混淆、处理 js 兼容问题、性能优化等强大的功能，从而让程序员把工作的重心放到具体的功能实现上，提高了开发效率和项目的可维护性。
• 五个核心概念：入口(Entry)、输出(Output)、Loader（加载器）、Plugins（插件）、Mode（模式）
  

二、webpack 的基本使用

2.1 在项目中安装和配置 webpack

① 运行 npm install webpack webpack-cli –D 命令，安装 webpack 相关的包

② 在项目根目录中，创建名为 webpack.config.js 的 webpack 配置文件

③ 在 webpack 的配置文件中，初始化如下基本配置：

module.exports = {
 mode: 'development' // mode 用来指定构建模式
}

④ 在 package.json 配置文件中的 scripts 节点下，新增 dev 脚本如下：

"scripts": {
"dev": "webpack" // script 节点下的脚本，可以通过 npm run 执行
}

⑤ 在终端中运行 npm run dev 命令，启动 webpack 进行项目打包。

2.2 配置打包的入口与出口

webpack 的 4.x 版本中默认约定：

• 打包的入口文件为 src -> index.js
• 打包的输出文件为 dist -> main.js

如果要修改打包的入口与出口，可以在 webpack.config.js 中新增如下配置信息：

const path = require('path') // 导入 node.js 中专门操作路径的模块
module.exports = {
 	entry: path.join(__dirname, './src/index.js'), // 打包入口文件的路径
 	output: {
 		path: path.join(__dirname, './dist'), // 输出文件的存放路径
 		filename: 'bundle.js' // 输出文件的名称
	}
}

2.3 配置 webpack 的自动打包功能

① 运行 npm install webpack-dev-server –D 命令，安装支持项目自动打包的工具

② 修改 package.json -> scripts 中的 dev 命令如下：

"scripts": {
 "dev": "webpack-dev-server" // script 节点下的脚本，可以通过 npm run 执行
}

③ 将 src -> index.html 中，script 脚本的引用路径，修改为 "/buldle.js“

④ 运行 npm run dev 命令，重新进行打包

⑤ 在浏览器中访问 http://localhost:8080 地址，查看自动打包效果

注意：

• webpack-dev-server 会启动一个实时打包的 http 服务器
• webpack-dev-server 打包生成的输出文件，默认放到了项目根目录中，而且是虚拟的、看不见的

2.4 配置 html-webpack-plugin 生成预览页面

① 运行 npm install html-webpack-plugin –D 命令，安装生成预览页面的插件

② 修改 webpack.config.js 文件头部区域，添加如下配置信息：

// 导入生成预览页面的插件，得到一个构造函数
const HtmlWebpackPlugin = require('html-webpack-plugin')
const htmlPlugin = new HtmlWebpackPlugin({ // 创建插件的实例对象
 template: './src/index.html', // 指定要用到的模板文件
 filename: 'index.html' // 指定生成的文件的名称，该文件存在于内存中，在目录中不显示
})

③ 修改 webpack.config.js 文件中向外暴露的配置对象，新增如下配置节点：

module.exports = {
 plugins: [ htmlPlugin ] // plugins 数组是 webpack 打包期间会用到的一些插件列表
}

2.5 配置自动打包相关的参数

// package.json中的配置
 // --open 打包完成后自动打开浏览器页面
 // --host 配置 IP 地址
 // --port 配置端口
 "scripts": {
 "dev": "webpack-dev-server --open --host 127.0.0.1 --port 8888"
 },

三、 webpack 中的加载器（loader）

1. 通过 loader 打包非 js 模块

在实际开发过程中，webpack 默认只能打包处理以 .js 后缀名结尾的模块，其他非 .js 后缀名结尾的模块，webpack 默认处理不了，需要调用 loader 加载器才可以正常打包，否则会报错！

loader 加载器可以协助 webpack 打包处理特定的文件模块，比如：

• less-loader 可以打包处理 .less 相关的文件
• sass-loader 可以打包处理 .scss 相关的文件
• url-loader 可以打包处理 css 中与 url 路径相关的文件

2. loader 的调用过程

四、webpack 中加载器的基本使用

1. 打包处理 css 文件

① 运行 npm i style-loader css-loader -D 命令，安装处理 css 文件的

② 在 webpack.config.js 的 module -> rules 数组中，添加 loader 规则如下：

// 所有第三方文件模块的匹配规则
module: {
	rules: [
 		{ test: /\.css$/, use: ['style-loader', 'css-loader'] }
	]
}

其中，test 表示匹配的文件类型， use 表示对应要调用的 loader

注意：

• use 数组中指定的 loader 顺序是固定的
• 多个 loader 的调用顺序是：从后往前调用

2. 打包处理 less 文件

① 运行 npm i less-loader less -D 命令

② 在 webpack.config.js 的 module -> rules 数组中，添加 loader 规则如下：

// 所有第三方文件模块的匹配规则
module: {
	rules: [
 		{ test: /\.less$/, use: ['style-loader', 'css-loader', 'less-loader'] }
	]
}

3. 打包处理 scss 文件

① 运行 npm i sass-loader node-sass -D 命令

② 在 webpack.config.js 的 module -> rules 数组中，添加 loader 规则如下：

// 所有第三方文件模块的匹配规则
module: {
	rules: [
		{ test: /\.scss$/, use: ['style-loader', 'css-loader', 'sass-loader'] }
	]
}

4. 配置 postCSS 自动添加 css 的兼容前缀

① 运行 npm i postcss-loader autoprefixer -D 命令

② 在项目根目录中创建 postcss 的配置文件 postcss.config.js，并初始化如下配置：

const autoprefixer = require('autoprefixer') // 导入自动添加前缀的插件
module.exports = {
	plugins: [ autoprefixer ] // 挂载插件
}

③ 在 webpack.config.js 的 module -> rules 数组中，修改 css 的 loader 规则如下：

module: {
	rules: [
		{ test:/\.css$/, use: ['style-loader', 'css-loader', 'postcss-loader'] }
	]
}

5. 打包样式表中的图片和字体文件

① 运行 npm i url-loader file-loader -D 命令

② 在 webpack.config.js 的 module -> rules 数组中，添加 loader 规则如下：

module: {
	rules: [
			{ 
			  test: /\.jpg|png|gif|bmp|ttf|eot|svg|woff|woff2$/, 
			  use: 'url-loader?limit=16940'
			}
		  ]
}

其中 ? 之后的是 loader 的参数项。

limit 用来指定图片的大小，单位是字节(byte),只有小于 limit 大小的图片，才会被转为 base64 图片

6. 打包处理 js 文件中的高级语法（babel）

① 安装babel转换器相关的包：npm i babel-loader @babel/core @babel/runtime -D

② 安装babel语法插件相关的包：

npm i @babel/preset-env @babel/plugin-transform
runtime @babel/plugin-proposal-class-properties –D 

③ 在项目根目录中，创建 babel 配置文件 babel.config.js 并初始化基本配置如下：

module.exports = {
	presets: [ '@babel/preset-env' ],
	plugins: [ '@babel/plugin-transform-runtime', '@babel/plugin-proposalclass-properties’ ]
}

④ 在 webpack.config.js 的 module -> rules 数组中，添加 loader 规则如下：

// exclude 为排除项，表示 babel-loader 不需要处理 node_modules 中的 js 文件
{ test: /\.js$/, use: 'babel-loader', exclude: /node_modules/ }

五、打包发布

项目开发完成之后 ，需要使用 webpack 对项目进行打包发布 ，主要原因有以下两点：

1. 开发环境下，打包生成的文件存放于内存中 ，无法获取到最终打包生成的文件
2. 开发环境下，打包生成的文件 不会进行代码压缩和性能优化

为了让项目能够在生产环境中高性能的运行，因此需要对项目进行打包发布。

5.1、配置webpack的打包发布

在 package.json 文件的 scripts 节点下，新增 build 命令如下

{
    ...
    "script": {
        "serve": "vue-cli-service serve"   // 开发环境中,运行dev命令
	    "build": "vue-cli-service build"   // 项目发布时,运行 build 命令 
    }
}

-- model 是一个参数项，用来指定 webpack 的运行模式 。production 代表生产环境，会对打包生成的文件
进行代码压缩和性能优化 。

注意：通过 -- model 指定的参数项，会覆盖 webpack.config.js 中的 model 选项

5.2、把JavaScript文件统一生成到js目录中

在 webpack.config.js 配置文件的 output 节点中，进行如下的配置

const path = require('path')

module.exports = {
    // 入口:可以是字符串/数组/对象，我们这里的入口只有一个，所以写一个字符串即可
    entry: path.join(__dirname,'./src/index.js')
    
    // 出口:通常是一个对象,里面至少包含两个重要属性,path 和 filename
    output :{
        // 注意: path通常是一个绝对路径
        path: path.resolve(__dirname,'dist'),
        // 明确告诉 webpack 把生成的 bundle.js 文件存放到 dist 目录下的 js 子目录中
        filename: 'js/bundle.js'
    }
}

5.3、把图片文件统一生成到 image 目录中

修改 webpack.config.js 中的 url-loader 配置项，新增 outputPath 选项即可指定图片文件的输出路径

{
    test: /\.jpg|png|gif$/,
    use: {
        loader: 'url-loader',
        options: {
            limit: 22228,
            // 明确指定把打包生成的图片文件,存储到 dist 目录下的 image 文件夹中    
            outputPath: 'image',
        }
    }
}

5.4、自动清理 dist 目录下的旧文件

为了在每次打包发布时自动清理掉 dist 目录中的旧文件 ，可以安装并配置 clean-webpack-plugin 插件

1. 安装插件

npm install clean-webpack-plugin --save-dev

2. 按需导入插件，得到插件的构造函数后，创建插件的实例对象

const {CleanWebpackPlugin} = require('clean-webpack-plugin')
const cleanPlugin = new CleanWebpackPlugin()

3. 把创建的 cleanPlugin 插件实例对象挂载到 plugins 节点中

// 1.导入清理插件插件,得到插件的构造函数后，创建插件的实例对象
const {CleanWebpackPlugin} = require('clean-webpack-plugin')
// 2.创建HTML插件的实例对象
const cleanPlugin = new CleanWebpackPlugin()

// 3.把创建的 cleanPlugin 插件实例对象,挂载到 plugins 节点中,使插件生效
module.exports = {
	mode: 'development',
    plugins: [htmlPlugin,cleanPlugin],		// 挂载插件		
}

六、Source Map

6.1、生产环境遇到的问题

前端项目在投入生产环境之前，都需要对JavaScript 源代码进行 压缩混淆 ，从而减小文件的体积，提高文件的加载效率。此时就不可避免的产生了另一个问题：

• 对压缩混淆之后的代码除错（debug）是一件极其困难的事情
• 变量被替换成 没有任何语义 的名称
• 空行和注释被剔除

6.2、什么是SourceMap

• Source Map就是一个信息文件，里面储存着位置信息
• 也就是说， Source Map 文件中存储着压缩混淆后的代码所对应的转换前的位置 。
• 有了它，出错的时候，除错工具将直接显示原始代码 ，而不是转换后的代码 ，能够极大的方便后期的调试。

6.2.1、webpack 开发环境下的 Source Map

在开发环境下，webpack 默认启用了 Source Map 功能。当程序运行出错时，可以直接在控制台提示错误行的位置，并定位到具体的源代码。

6.2.2、默认Source Map的问题

开发环境下默认生成的 SourceMap ，记录的是 生成后的代码的位置 。会导致运行时报错的行数与源代码的行数不一致的问题。示意图如下：

6.2.3、解决默认Source Map的问题

开发环境下，推荐在 webpack.config.js 中添加如下的配置，即可保证运行时报错的行数与源代码的行数保持一致

module.exports = {
    mode: 'development',
    // eval-source-map 仅限在'开发模式'下使用,不建议在 '生产模式'下使用。
    // 此选项生产的 Source Map 能够保证运行时报错的行数与源代码的行数保持一致
    devtool: 'eval-source-map',
}

6.3、webpack生产环境下的SourceMap

在生产环境下 ，如果省略了 devtool 选项 ，则最终生成的文件中不包含 Source Map 。这能够防止原始代码通过Source Map 的形式暴露给别有所图之人。

6.3.1、只定位行数不暴露源码

在生产环境下，如果 只想定位报错的具体行数 ，且不想暴露源码 。此时可以将 devtool 的值设置为nosources-source-map 。实际效果如图所示：

6.3.2、定位行数且暴露源码

在生产环境下，如果想在定位报错行数的同时，展示具体报错的源码。此时可以将 devtool 的值设置为 source-map。实际效果如图所示：

6.4、Source Map最佳实践

• 开发环境下
  1. 建议把 devtool 的值设置为 eval-source-map
  2. 好处：可以精准定位到具体的错误行
• 生产环境下
  1. 建议关闭 Source Map 或将 devtool 的值设置为 nosources-source-map
  2. 好处：放置源码泄露，提高网站的安全性

总结：实际开发中不需要自己配置webpack

• 实际开发中会使命令行工具（俗称 CLI）一键生成 带有 webpack 的项目
• 开箱即用，所有 webpack 配置项都是现成的
• 但是我们仍需要了解配置项的基本概念

这篇好文章是转载于：学新通技术网