大家好，我是小菜。一个希望成为谈建筑的吹牛X的男人！如果你也想成为我想成为的人，或者跟着我做伴，让小菜不再孤单！本文主要介绍Webpack的使用。有需要的可以参考前端了解很多人对前端开发有一些误区。他们觉得会H5+C3+JS就相当于会前端开发。不过近些年来，前后端分离的模式逐渐流行起来，这意味着前端不再像以前那么简单了。.从我对后端的角度来看，感觉前端是文官，后端是武将。不能说他文武双全，但至少在修武的同时，也得略知一二。退一两步，前端实习妹子遇到BUG手足无措的时候，如果你能在虚幻世界的前端帮帮我~那在她眼里，你就是“来者不拒的英雄”有彩云~”如果你知道Bootstrap和Layui，那么如果你知道前端，难免会被拍死在沙滩上~实际的前端开发由以下几个模块组成：模块化（js的模块化，模块化css化、资源模块化）组件标准化（复用现有UI结构、样式、行为）规范化（目录结构划分、编码标准化、接口标准化、文档标准化、Git分支管理）自动化（自动化构建、自动化部署、自动化测试）和后端完全一样，所有模块都可用。说到工程化，后端开发有Maven项目、Gradle项目等主流方案。前端工程解决方案还包括webpack和vite。那么让我们进入今天的主题，走进WebpackWebpack一、概念认知webpack本质上是现代JavaScript应用的静态模块打包工具。当webpack处理一个应用程序时，它会在内部从一个或多个入口点构建一个依赖图，然后将你项目中需要的每个模块组合成一个或多个bundle，这些都是静态资源，用来展示你的内容。以上内容摘自官网，以官方为准。下面简单总结下概念：webpack是前端项目工程化的具体解决方案功能总结：为前端模块化开发提供友好支持提供代码压缩混淆、处理浏览器兼容Js、性能优化等强大功能总结:提高前端开发效率和项目的可维护性。2.基础使用实践出真知！我们直接使用它来加强我们的理解。首先我们需要创建一个空白目录，然后在空白目录下执行npminit-y初始化包管理配置文件package.json，可以简单理解为这个package.json相当于pom.xml文件在Maven项目中的maven项目中我们一般将源码放在src目录下。webpack项目类似，所以我们下一步就是在该目录下创建src目录，然后创建index.html（首页）和index.js（脚本文件）两个文件，传统上我们需要导入Jquery文件。一般来说，有两种方式。一种是下载jquery.mini.js文件，然后将导入到项目中。一种是参考网上已有的CDN库，这样就不需要下载每种方法都有优缺点，这里就不多解释了！由于我们的项目是用npm初始化的，所以我们可以使用npm来帮我们下载需要的包。npminstalljquery-s添加成功后，我们可以在package.json文件中看到我们刚刚下载的包。这个方法是不是让你想起了maven的maveninstall命令？这种奇怪的熟悉感~jquery包安装好后，我们可以在node_modules目录下查看。然后在项目中引用该包。浏览器检查JS是否正常运行。上面的方法也是传统的导入包的方式，和webpack还是没有关系的。接下来，我们就来看看webpack是如何使用的。1、webpack安装在终端执行如下命令安装webpack相关的两个包：npminstallwebpack@5.42.1webpack-cli@4.7.2-Dextensionnpminstallxxx-S即npminstallmodule_name--savewritedependenciesnpminstallxxx-D，即npminstallmodule_name--save-dev写devDependenciesdevDependencies，这是我们开发时需要用到的一些包。它们只需要在开发阶段使用，真正打包上线时就不需要这些包了，依赖项，这个需要发布到生产环境。2、webpack配置我们需要在项目根目录下创建一个名为webpack.config.js的webpack配置文件，并初始化如下基本配置：module.exports={mode:"development"}其中mode是一个变量值,有两个可选值development1,适合开发环境2,打包后的文件不做代码压缩和性能优化3,打包速度快,适合开发阶段使用,可以快速响应页面变化production1,适用到生产环境2.打包生成的文件会进行代码压缩和性能优化3.打包速度很慢，只适合在项目发布阶段使用1）配置文件webpack.config的作用。js是webpack的配置文件，webpack在真正开始打包构建之前，会先读取这个配置文件，从而根据th打包项目e给定的配置。由于webpack是基于node.js开发的打包工具，所以在其配置文件中支持node。webpack个性化配置的.js相关语法和模块，然后我们在这里做一个加载点①，回到刚才说的webpack的使用，后面再回来介绍webpack！Java中有一句耳熟能详的说法：everythingAllobjects，所以我们在前端工程中也有一句话：everythingisamodule，我们不再需要传统的js导入方式：我们可以在需要的地方导入jquery。页面index.html需要jquery吗？不需要，index.js脚本文件需要，所以我们只需要在index.js文件中导入即可然后我们还需要修改package.json文件：我们添加了一个dev脚本，脚本script节点下可以通过npmrun来执行。然后我们在终端运行npmrundev命令，启动webpack打包构建项目，很快！在项目目录下生成一个dist目录，存在main.js脚本文件。我们再在index.html文件中引入main.js文件，先直接看结果，我们可以右键在浏览器中打开，发现js运行正常，那么main.js是什么？在**webpack4.x和5.x**版本中有如下默认约定：默认包入口文件为src/index.js默认输出文件路径为dist/main.js规定为die，人是有生命的，所以我们可以修改包中的webpack.config.js默认约定！明白了约定，我们就可以知道index.js的内容包含在main.js中了，我们可以直接查看main.js文件，结果如我们所料：我们回到了之前的加载点①继续刚才的webpack.config.js配置文件的说明在webpack.config.js文件中，我们可以通过entry节点指定包入口，然后通过output节点指定包出口。这就是我们上面所说的打破默认规则！上面我们也说完了webpack的基本使用，下面我们来看看webpack中插件的使用。配置第三方插件可以扩展webpack的能力，让webpack使用起来更加方便。最常用的webpack有两个：webpack-dev-server1，类似于node.jsstage2中使用的nodemon工具，每当修改源代码时，webpack会自动打包构建项目html-webpack-plugin1，类似基于一个模板引擎2.可以通过这个插件自定义index.html页面的内容先来看看第一个插件的使用方法1)webpack-dev-serverwebpack-dev-server允许webpack对监控项目源码变化，从而自动打包构建①安装使用如下命令在项目中安装插件npminstallwebpack-dev-server@3.11.2-D②配置1.需要修改脚本"scripts"inpackage.json:{"dev":"webpackserver"}2.运行npmrundev命令，可以看到一句话：Theprojectisrunningonlocalhost:8080/。而且运行之后，并没有出现dist目录。然后我们通过这个地址访问但是没有看到我们想要的页面。相反，我们需要单击src目录才能访问。根据以上结果，我们可能会有以下疑问：为什么会出现npmrundev？访问地址呢？这是因为webpack-dev-server会启动一个实时打包的http服务器。打包后的文件在哪里生成？要回答这个问题，我们需要知道两件事——配置和不配置webpack-dev-servers的区别1.如果没有配置webpack-dev-server，webpack打包生成的文件会存放在实际物理上disk（按照output指定的路径存放）2.配置webpack-dev-server时，打包生成的文件会存放在内存中，而不是output节点指定的路径。这样的好处是提高了实时打包输出的性能，所以内存比物理磁盘快很多。如何访问内存中生成的文件？内存中生成的文件默认放在项目的根目录下，但是是虚拟的，不可见的。我们可以直接用/表示项目的根目录，后面跟着要访问的文件名，来访问内存中的文件。结束三个问题，说说下一个插件html-webpack-plugin2)html-webpack-plugin我们访问上面webpack服务器给的url地址，发现不能直接访问我们的index页面，难免有一些缺陷。有缺陷就会有改进，可以说说插件html-webpack-plugin~！①老办法安装，我们需要通过如下命令安装npminstallhtml-webpack-plugin@5.3.2-D②配置③运行我们通过运行npmrundev，然后通过插件查看结果，我们可以看到页面可以直接通过路径访问了~这里有朋友可能会问了，如果我不想通过8080端口，我可以通过localhost吗？是吗？答案是可以的，我们可以通过devServer节点配置更多的webpack-dev-server插件：devServer:{//第一次打包成功后，浏览器会自动打开open:true,//在http协议中，如果端口号是80，可以省略port:8081,//指定运行主机地址host:'127.0.0.1'}，那么我们运行项目，通过127.0.0.1:8081访问页面：我们已经介绍过了到这里就把这两个插件的使用都介绍完了，接下来我们再看点不一样的~！四、loader的使用我们开头已经说过一句话，在前端工程中，万物皆模块。所以我们可以在index.js脚本文件中导入jquery的js文件。遇到css文件是否可以导入？我们不妨试一试：当我们想通过import导入css文件时，控制台给了我们一句话：YoumayneedanappropriateloadertohandlethisFiletype,appropriate?loader?。那么进入正题，什么是loader！在实际开发过程中，webpack默认只能打包处理以.js后缀结尾的模块。其他不以.js后缀名结尾的模块是无法被webpack处理的，也就是会出现上面的情况，但是如何处理呢？正如提示文字所说，我们需要下载一个合适的加载器来处理这种文件类型。loader加载器有很多种，但是它们的作用只有一个，就是帮助webpack打包处理特定的文件模块css-loader：可以打包处理.css相关的文件less-loader：可以打包处理.less相关的文件babel-loader：可以打包处理webpack无法处理的高级JS语法。接下来我们来处理上面cssimportpackage的问题。.6-D②配置我们需要在webpack.config.js文件模块中配置相应的loader规则：{rules:[//处理.css文件的loader{test:/\.css$/,use:['style-loader','css-loader']},]}③运行然后我们运行文件，浏览器看到效果。结果已经说明css-loader发挥了作用。看看规则是怎么写的：{test:/\.css$/,use:['style-loader','css-loader']}其中test表示匹配的文件类型，use表示对应的loader顺序在加载程序中使用要调用的数组是固定的。多个loader的调用顺序是从后往前。其他loader的用法同上。它们都需要先安装，然后在webpack.config.js文件中配置1)less-loader安装npmiless-loader@10.0.1less@4.1.1-D配置模块：{rules:[//loader进行处理.cssfiles{test:/\.css$/,use:['style-loader','css-loader']},//处理.less文件的loader{test:/\.less$/,use:['style-loader','css-loader','less-loader']},]}2)babel-loader安装npmibel-loader@8.2.2@babel/core@7.14.6@babel/plugin-proposal-decorators@7.14.5-D配置模块:{rules:[//processing.css文件加载器{test:/\.css$/,use:['style-loader','css-loader']},//Processing.lessfileloader{test:/\.less$/,use:['style-loader','css-loader','less-loader']},//处理JS高级语法的loader{test:/\.js$/,use:'babel-loader',exclude:/node_modules/}]}上面我们看到了几个loader的作用，那么处理流程是怎样的呢？我们用一张图来说明一下：5.打包发布完成了上面的项目开发之后，我们就来到了打包发布阶段，之前所做的一切最后肯定是要发布的，所以为了让项目在生产环境中高性能运行，需要对项目进行打包发布。①配置，打包和发布也需要配置，我们需要在package.json文件下的script节点配置：其中--model是一个参数项，用来指定webpack的运行方式，我们已经介绍过了itabove~然后通过命令npmrunbuild，我们可以在项目的根路径下看到我们熟悉的dist目录，但是如果没有指定规则配置，打包后的文件会放在dist目录下默认，但是如果我们想把js文件放在js目录下，图片文件放在image目录下。我们需要在webpack.config.js中进行相应的配置。在通过输出节点配置好我们js文件的生成目录之前，我们还需要配置其他文件的输出。directory，下面是一个图片类型文件的例子：我们也是在webpack.config.js文件中配置的，不过这次是在rules节点中配置的：至此我们已经差不多完成打包任务了，但是如果我们改变了js的生成目录，这时候会发生什么？我们发现会产生冗余文件，旧文件并没有被删除。是否需要手动删除每个包？当然不是！自动清理dist目录下的旧文件，可以安装配置clean-webpack-plugin插件安装npminstallclean-webpack-plugin@3.0.0-D配置运行六、源码映射本源Map有点意思，我们后台上线后，如果有问题，我们一般会去服务器查看错误日志。那么如果前端有问题就很方便了。我们可以直接通过F12打开控制台查看错误日志，也可以调试js文件。但是我们上面说了，通过mode指定生产值后代码会被压缩，所以调试是一件极其困难的事情。SourceMap就是用来解决这类问题的。1）ConceptSourceMap是一个信息文件，里面存放的是位置信息，即转换后的位置映射->转换前。有了它的帮助，当出现错误时，可以直接显示原始代码，而不是转换后的压缩代码，可以在一定程度上提高排查效率。2）正常使用在开发环境中，webpack默认开启SourceMap功能。当程序运行不正确时，可以直接在控制台提示错误位置信息，但这种提示并不友好。它记录了压缩后代码的位置，由此造成的问题是实际运行报错的行数与源代码的行数不符，会成为我们排查路上的绊脚石~！既然如此，我们就以问题来解决！3）So遇到的问题①问题一：实际运行报错的行数与源码中的行数不符。那么解决这个问题就很简单了。需要在webpack.config.js中添加如下配置：配置完成后查看结果，我们现在可以发现运行报错的行数与源码的行数一致！②问题二：生产环境容易暴露源码。虽然上面我们已经能够定位到源码错误，但是如果是在生产环境中，源码并不总是容易暴露的。这是一件好事，所以让我们也修复它。解决这个问题的方式也很暴力。直接打包时，在webpack.config.js文件中指定mode为production，这样就不会显示错误行数，也不会显示源码内容。mode:"production"③问题三：生产环境需要显示行号，隐藏源码。上面的方法太暴力了，行号和源码都不给你看。有没有办法比较这个，可以显示行数但不能显示源代码？答案必须是肯定的！我们只需要将devtool的值配置为nosources-source-mapdevtool:'nosources-source-map'配置完成后，我们来看看效果：这个方法可以显示错误行数，隐藏源码，即一个非常合适的解决方案。所以总结一下4）在开发环境中，将devtool的值设置为eval-source-map，有利于准确定位到具体的错误行。在生产环境中，关闭SourceMap或者将devtool的值设置为nosource-source-map，有利于防止源码泄露，提高安全性
