前端工程化与webpack
前端工程化与webpack
1. 前端工程化
实际上的前端开发：
- 模块化（js模块化，css模块化，资源模块化）
- 组件化（复用现有的UI结构、样式、行为）
- 规范化（编码规范、接口规范、文档规范、Git分支管理）
- 自动化（自动化构建、自动部署、自动化测试）
1.1 前端工程化是什么？
前端工程化：在企业及的前端项目开发中，把前端开发所需的工具、技术、流程、经验等进行规范化和标准化。
早期的前端工程化解决方案：gulp、grunt等
目前主流的前端工程化解决方案：webpack、parcel
2. webpack的基本使用
2.1 webpack是什么？
webpack: 是前端工程化的具体解决方案。
主要功能：提供了友好的前端模块化开发支持，以及代码压缩混淆，处理浏览器端JavaScript的兼容性，性能优化等强大的功能。
好处：让技术人员将工作重心放在具体功能的实现上，提高了前端开发的效率和项目的可维护性
2.2 webpack安装
当我们在项目中想用ES6语法引入jQuery会报语法错误，有兼容性问题，想用webpack解决
在项目中安装webpack： npm install webpack webpack-cli -D
dependencies节点：开发+上线 -S –save
devDependencies节点: 仅开发阶段 -D –save-dev
2.3 webpack配置
在项目根目录下创建webpack.config.js的webpack配置文件，并初始化
module.exports = {
mode: ‘development’
}
*mode的可选值
在package.json的scripts节点下新增dev脚本
“scripts”: {
“dev”: “webpack”
}
scripts节点下的脚本可以通过npm run执行， 比如这里定义dev脚本，就是npm run dev
在终端运行我们定义好的脚本命令：npm run dev，启动webpack对项目进行打包构建
最后将打包构建好的main文件导入，删掉有兼容性问题的文件
2.4 webpack默认约定
在webpack4.x和5.x的版本中，有以下的默认约定：
- 默认的打包入口文件为：src -> index.js
- 默认的输出文件路径为：dist -> main.js
这个约定对名字很敏感，如果想要修改就需要通过webpack.config.js配置文件来修改
2.5 自定义打包的入口和出口
在webpack.config.js中，通过entry节点指定打包的入口，通过output节点指定打包的出口
entry: path.join(__dirname, ‘./src/index.js’),
output: {
path: path.join(__dirname, ‘./dist’),
filename: ‘bundle.js’
}
那么，每次修改代码都需要重新运行npm run dev很麻烦
3. webpack插件
通过安装和配置第三方的插件，可以拓展webpack的能力，从而用起来更加的方便
3.1 webpack-dev-server
安装：npm install webpack-dev-server@3.11.2 -D
配置：将package.json -> scripts中的dev命令修改
“dev”: “webpack serve”
再次运行npm run dev的命令
可以在localhost:8080查看自动打包效果
问题：为什么页面并不会自动显示变化？
答：webpack-dev-server并不能读取webpack.config.js中配置的output属性，默认打包的文件名是bundle.js,且不会出现在项目目录中。所以将index.html中引入js文件的路径直接换成’bundle.js’即可！
3.2 html-webpack-plugin
安装：npm install html-webpack-plugin@5.3.2 -D
配置：在webpack.config.js中
4. webpack中的loader
引入：在实际开发中，webpack默认只能打包处理以.js后缀名结尾的模块。所以打包其他非js文件比如图片、css、字体等其他类型的资源文件均是基于Loader机制来实现的。
4.1 loader加载器的作用
协助webpack打包处理特定的文件模块，如：
- css-loader：打包处理.css相关的文件
- less-loader: 打包处理.less相关的文件
- babel-loader: 打包处理webpack无法处理的高级js语法
4.2 loader的调用过程
4.3 打包处理css文件
webpack允许用户为某些资源文件配置多个不同的loader，在处理 .css文件的时候，用到了style-loader和css-loader
安装： npm i style-loader@3.0.0 css-loader@5.2.6 -D
配置： webpack.config.js中module -> rules数组中添加loader规则
rules: [
{ test: / \ .css$/, use: [‘style-loader’, ‘css-loader’]}//注意顺序是固定的！
]
其中test是要匹配的文件类型，use是要对应调用的loader
多个loader的调用顺序是：从后往前调用
过程：webpack先将.css后缀的文件交给use的最后一个loader(css-loader)处理完毕后，交给倒数第二个loader(style-loader)处理后，发现没有别的loader了就交给webpack,最终合并到main.js中。
4.3 打包处理less文件
安装： npm i less-loader@10.0.1 less@4.1.1 -D
配置： webpack.config.js中module -> rules数组中添加loader规则
rules: [
{ test: / \ .less$/, use: [‘style-loader’, ‘css-loader’, ‘less-loader’]}
]
4.4 打包处理样式表中与url路径相关的文件
安装： npm i url-loader@4.1.1 file-loader@6.2.0 -D
配置： webpack.config.js中module -> rules数组中添加loader规则
rules: [
{ test: / \ .jpg|png|gif$/, use: ‘url-loader?limit=22229’}
]
?后面是loader的参数，limit指定图片的大小，也就是说只有<=limit大小的图片才会被转为base64格式的图片。
4.5 打包处理js文件中的高级语法
webpack只能打包处理一部分高级的js语法，对于webpack不能处理的，需要借助babel-loader进行打包处理。
安装： npm i babel-loader@8.2.2 @babel/core@7.14.6 @babel/plugin-proposal-decorators@7.14.5 -D
配置： webpack.config.js中module -> rules数组中添加loader规则
rules: [
{ test: / \ .js$/, use: ‘babel-loader’, exclude: /node_modules/}//node_modules目录下的第三方包不需要被打包
]
配置：在项目根目录下创建 babel.config.js 并配置
module.exports = {
//声明babel可用插件
plugins: [[‘@babel/plugin-proposal-decorator’, {legacy: true}]]
}
5. 打包发布
5.1 为什么要用webpack进行打包发布？
项目开发完成之后，需要使用webpack打包发布的原因有如下两条：
- 开发环境下，打包生成的文件存放在内存中，无法获取到最终打包生成的文件
- 开发环境下，打包生成的文件不会进行代码的压缩和性能的优化。
5.2 webpack打包发布的配置
在package.json文件中的Scripts节点下，新建build命令：
“build”: “webpack –mode production”
6. source map
在已经压缩混淆之后的代码进行debug是一件及其困难的事情，因为所有的空格和注释都被删除并且变量被替换成没有任何语义的名称
6.1 什么是SourceMap？
SourceMap是一个信息文件，里面存储了位置信息：压缩混淆后的代码与源代码的对应关系。
在出错的时候，除错工具直接显示原始代码，而不是压缩后的代码，方便调试。
6.2 webpack开发环境下的SourceMap
- 在开发环境下，webpack默认启用了sourcemap功能。
问题： 开发环境下默认生成的SourceMap记录的是生成后的代码位置，会导致报错的位置和源代码的位置不一样。
解决方案：在webpack.config.js中配置在开发环境下的devtool
devtool: ‘eval-source-map’
- 在生产环境下，应该省略devtool选项，防止泄露源代码
问题：可是我还想找到出问题的源码
解决方案：将devtool的值设置为nosources-source-map，就可以只定位报错的具体行数而不暴露源代码