前端打包工具 —— webpack (四.其他拓展)
配置解决导入模块后缀名的配置
首先我们的 webpack 打包工具对于我们的一些后缀名的文件的导入是自动补全的
但是只不过在我们后面的开发中会使用到其他的更多的后缀名文件
所以说这个时候我们就可以直接通过配置我们的 webpck.config.cjs 来实现我们的配置
这里主要是两个配置项
- resolve.extensions 就是用来实现配置我们的文件扩展名使用的
- resolve.alias 就是为我的一个自定义工具的路径书写别名的 webpack 配置
resolve: { // 拼接文件后缀 extensions: ['.js', '.vue', ".jsx", ".ts", ".tsx", ".cjs", ".mjs", ".json"], // 配置别名 alias: { utils: path.resolve(__dirname, './src/utils'), } },
认识 webpack 中的插件 Plugin
插件(plugin)是用来实现的是我们的执行完成更加广泛的任务,比如说打包优化,资源管理,环境变量注入的功能实现
Loader 只是一个用于特定模块类型的一种转换工具
css-loader less-loader sass-loader postcss-loader style-loader vue-loader babel-loader- 上面的列举出来的一些插件只是用来实现的是我们的特定模块类型文件的转换罢了
CleanWebpackPlugin
- 该插件可以帮助我们的是在每次进行项目打包的时候,都进行一次自动的删除前一次打包的文件目录,然后再继续打包
npm install clean-webpack-plugin -Dconst { CleanWebpackPlugin } = require("clean-webpack-plugin")plugins: { new CleanWebpackPlugin(), }
但是通过阅读官网我们可以知道的是 webpack 已经使用了我们的
clean配置项来替代该插件中具备的一些简单功能了
- 只要在我们的 output 中设置:
clean: true即可开启该插件具备的功能
HtmlWebpackPlugin
通过我们这几天的讲解中,我们现在的打包流程还是十分的不规范的
因为我们使用 webpack 以及 vite 打包工具的宗旨一直是进行把打包后的 dist 文件直接部署在我们的服务器中
但是我们现在的配置的打包文件存在的问题就是,没有 html 文件呀,加载页面的工具 html 都没得,看个啥呀!!!
这个时候我们该如何做耶???
这个时候就可以使用我们当前的 HtmlWebpackPlugin 插件了
npm install html-webpack-plugin -D
const HtmlWebpackPlugin = require("html-webpack-plugin")
plugins: { new HtmlWebpackPlugin (), }同时在内部我们也是可以直接通过向内部传递一个对象来指定我们的整个项目的标题的
new HtmlWebpackPlugin ({ title: "juwenzhang_webpack_demo" })- 同时还可以自定义最终生成的 html 文件模板的。通过
template字段来实现,其内部使用的语法是 ejs 语法
DefinePlugin
该插件用来实现的是自定义我们的插件类型
但是这个插件的话是 webpack 是内置的插件
const { DefinePlugin } = require("webpack")同时我们的该插件在我们使用的时候,就给予了一个内置的变量:
process.env-NODE_ENV
- 该变量和下面的 mode 对应的值是息息相关的
new DefinePlugin({ // 这里就是书写的是一些全局变量 BASE_URL: "'./'", juwenzhang: "'juwenzhang'" }),
Mode 配置
这个就是我们模式的配置了
mode 的配置就是实现的是我们的告诉 webpack 我们正处于什么样的环境之下
处于不同的环境中的时候,webpack 就会使用不同的模式进行不同的内置优化
默认值是生产模式
production可设置的值含有:
"none" | "development" | "production"基本规则的话就是:
- 在我们正处于开发的阶段的话,那就直接设置为
development- 在我们准备部署上线的时候就可以直接设置为
production
webpack 启动本地服务器
搭建我们本地服务器的原因是为了能够便利前端的开发
实现让我们在进行开发的途中也是可以自动化的看到我们进行的修改
所以说这就需要进行我们的启动本地服务器,实现动态的查看开发的效果
为了实现完成我们的 webpack 的自动化的编译,webpack 给我们提供方式:
webpack watch mode
- 可以实现自动编译,但是不会刷新浏览器
webpack-dev-server(常用)
- 可以实现自动编译,并且实现刷新浏览器
webpack-dev-middleware
webpack-dev-server
- 这个就是我们开发阶段的 webpack 服务器
npm install webpack-dev-server -D"serve": "npx webpack serve --config webpack.config.cjs"npm run serve
模块热替换(HMR)
在实现了上面的配置后,我们的打包实现的是我们的一个模块中的内容发生了变化,那么最后整个项目进行重新打包
但是这个将整个项目进行重新的打包的操作是很不必要的,为了提高我们的打包流程,我们就需要使用到模块热替换
来从一定程度上优化该打包过程,实现每次打包只是对我们的修改的部分进行打包即可
模块热替换具体实现的操作就是:(Hot Module Replacement)
- 应用程序在运行过程中,实现替换,添加,删除模块的操作,而无需重新刷新整个页面
手动配置本地服务器
- 这个就是自定义我们的 devServer 来实现的配置
- port 设置访问端口
- host 设置主机
- open 决定我们启动服务时候是否自动打开浏览器
- compress 设置文件是否进行压缩
devServer: { hot: true, // 默认开启的,开启热模块替换 port: 8080, // 端口修改 open: true, // 配置启动服务时是否打开浏览器 compress: true, // 设置我们的文件是否压缩 }
同时这里我们还需要注意一点,我们的工程化开发中,一般具备几个配置文件:测试环境、生产环境、开发环境等等
所以说一般看一些开源项目的话,就会发现一点的是,就具备一个 configs 或者说执行脚本 scripts 文件目录来存放一些不同的配置项
一般我们可以配置的文件可以分为:
webpck.common.config.cjs 用来存放的是我们的配置一些公共的配置
webpack.prod.config.cjs 用来配置的是生成环境的配置
webpack.dev.config.cjs 用来配置的是开发环境中的配置
webpack.test.config.cjs 用来配置的是测试环境的配置
同时在这个步骤中我们还是会接触到一个新的插件,用来实现我们后续的合并相同配置部分的合并依赖: webpack-merge
- 为什么我这里列出来的是以 .cjs 为后缀的文件名
- 是因为我们的 webpack 进行调用的时候运行的环境是我们的 NodeJs
- 但是 NodeJs 中支持的规范是 commonjs 规范,虽然也是支持 esmodule 规范的(比较麻烦)
- 但是还是以 commonjs 规范为主,为了后续的编译的时候,容易识别,所以说就有了我们以 .cjs 为后缀名的配置