网站颜色正确搭配实例,公司网站设计好,芯片设计公司排名,中小企业建站的方法1、什么是Webpack#xff1f;
Webpack是一个开源的JavaScript模块打包工具#xff0c;其最核心的功能是解决模块之间的依赖#xff0c;把各个模块按照特定的规则和顺序组织在一起#xff0c;最终合并为一个JS文件#xff08;有时会有多个#xff0c;这里讨论的只是最基本…1、什么是Webpack
Webpack是一个开源的JavaScript模块打包工具其最核心的功能是解决模块之间的依赖把各个模块按照特定的规则和顺序组织在一起最终合并为一个JS文件有时会有多个这里讨论的只是最基本的情况。这个过程就叫作模块打包。
你可以把Webpack理解为一个模块处理工厂。我们把源代码交给Webpack由它去进行加工、拼装处理产出最终的资源文件等待送往用户。
没有接触过打包工具的人可能会疑惑在Web开发中与我们打交道的无非是HTML、CSS、JS等静态资源为什么不直接将工程中的源文件发布到服务器或CDN而要交给Webpack处理呢这两者之间有什么不同接下来我们就来阐述使用Webpack的意义。
2、为什么需要Webpack
开发一个简单的Web应用其实只需要浏览器和一个简单的编辑器就可以了。最早的Web应用就是这么开发的因为需求很简单。当应用的规模大了之后就必须借助一定的工具否则人工维护代码的成本将逐渐变得难以承受。使用工具可以让开发效率成倍地提升所谓“工欲善其事必先利其器”就是这个意思。
说回Webpack既然它解决的最主要问题是模块打包那么为了更好地阐述Webpack的作用我们必须先谈谈模块。
2.1、模块
我们每时每刻都在与模块打交道比如在工程中引入一个日期处理的npm包或者编写一个提供工具方法的JS文件这些包和文件都可以称为模块。
在设计程序结构时把所有代码都堆到一起是非常糟糕的做法。更好的组织方式是按照特定的功能将其拆分为多个代码段每个代码段实现一个特定的目的。你可以对其进行独立的设计、开发和测试最终通过接口来将它们组合在一起。这就是基本的模块化思想。
如果把程序比作一个城市这个城市内部有不同的职能部门如学校、医院、消防局等。程序中的模块就像这些职能部门一样每一个都有其特定的功能。各个模块协同工作才能保证程序的正常运转。
2.2、JavaScript中的模块
在大多数程序语言如C、C、Java中开发者都可以直接使用模块进行开发。工程中的各个模块在经过编译、链接等过程后会被整合成单一的可执行文件并交由系统运行。
对于JavaScript来说情况则有所不同。在过去的很长一段时间里JavaScript这门语言并没有模块这一概念。如果工程中有多个JS文件我们只能通过script标签将它们一个个插入页面中。
为何偏偏JavaScript没有模块呢如果要追溯历史原因JavaScript之父Brendan Eich最初设计这门语言时只是将它定位成一个小型的脚本语言用来实现网页上一些简单的动态特性远没有考虑到会用它实现今天这样复杂的场景模块化当然也就显得多余了。
随着技术的发展JavaScript已经不仅仅用来实现简单的表单提交等功能引入多个script文件到页面中逐渐成为一种常态但我们发现这种做法有很多缺点
需要手动维护JavaScript的加载顺序。页面的多个script之间通常会有依赖关系但由于这种依赖关系是隐式的除了添加注释以外很难清晰地指明谁依赖了谁所以当页面中加载的文件过多时很容易出现问题。每一个script标签都意味着需要向服务器请求一次静态资源在HTTP 2还没有出现的时期建立连接的成本是很高的过多的请求会严重拖慢网页的渲染速度。在每个script标签中顶层作用域即全局作用域没有任何处理而直接在代码中进行变量或函数声明会污染全局作用域。
模块化则解决了上述所有问题
通过导入和导出语句我们可以清晰地看到模块间的依赖关系这点在后面会做详细的介绍。模块可以借助工具来进行打包所以在页面中只需要加载合并后的资源文件减少了网络开销。多个模块之间的作用域是隔离的彼此不会有命名冲突。
从2009年开始JavaScript社区开始对模块化进行不断的尝试并先后给出了AMD、CommonJS、CMD等解决方案。但这些都只是由社区提出的并不能算作语言本身的特性。而在2015年ECMAScript 6.0ES6正式定义了JavaScript模块标准使这门语言在诞生了20年之后终于拥有了模块这一概念。
ES6模块标准目前已经得到了大多数现代浏览器的支持但在实际应用方面还需要等待一段时间主要有以下几点原因
无法使用代码分片code splitting和删除死代码tree shakingWebpack的两个特别重要的特性后文会介绍。大多数npm模块还是CommonJS的形式而浏览器并不支持其语法因此这些包没有办法直接拿来用。仍然需要考虑个别浏览器及平台的兼容性问题。
那么如何才能让我们的工程在使用模块化的同时也能正常运行在浏览器中呢这就到了模块打包工具出场的时候了。
2.3、模块打包工具
模块打包工具module bundler的任务就是解决模块间的依赖使其打包后的结果能运行在浏览器上。它的工作方式主要分为两种
将存在依赖关系的模块按照特定规则合并为单个JS文件一次全部加载进页面中。在页面初始时加载一个入口模块异步加载其他模块。
目前社区中比较流行的模块打包工具有Webpack、Vite、Parcel、Rollup等。
2.4、为什么选择Webpack
对比同类模块打包工具Webpack具备以下几点优势
Webpack默认支持多种模块标准包括AMD、CommonJS以及最新的ES6模块而其他工具大多只能支持一到两种。Webpack对于一些同时使用多种模块标准的工程非常有用它会帮我们处理好不同类型模块之间的依赖关系。Webpack有完备的代码分片解决方案。从字面意思去理解它可以分割打包后的资源在首屏只加载必要的部分将不太重要的功能放到后面动态加载。这对于资源体积较大的应用来说尤为重要可以有效地减小资源体积提升首页渲染速度。Webpack可以处理各种类型的资源。除了JavaScript以外Webpack还可以处理样式、模板甚至图片等而开发者需要做的仅仅是导入它们。比如你可以从JavaScript文件导入一个CSS或者PNG而这一切最终都可以由loader来处理。Webpack拥有庞大的社区支持。除了Webpack核心库以外还有无数开发者来为它编写周边插件和工具。对于绝大多数的需求你都可以直接在社区找到已有解决方案甚至会找到多个解决方案。
3、安装Webpack
Webpack对于操作系统没有要求使用Windows、Mac、Linux操作系统均可。它唯一的依赖就是Node.js下面来进行安装。
Webpack对Node.js的版本是有一定要求的推荐使用Node.js的LTSLong Term Support长期维护版本。LTS版本是Node.js在“当前阶段”较为稳定的版本具体版本号及发布计划可以到https://github.com/nodejs/Release自行查看。LTS版本中不会包含过于激进的特性并且已经经过了一定时间的检验比较适合生产环境。大多数Node.js模块也都会依照LTS版本的特性提供支持。
Node.js官网https://nodejs.org/一般都会把LTS版本放在较为醒目的位置用户根据自己的系统环境进行下载和安装即可。安装完成后打开命令行并执行node-v不出意外的话会显示当前Node.js的版本号代表已经安装成功。
接下来我们需要使用Node.js的包管理器npm来安装Webpack。使用过npm的读者应该知道安装模块的方式有两种一种是全局安装一种是本地安装。对于Webpack来说我们也有这两种选择。
全局安装Webpack的好处是npm会帮我们绑定一个命令行环境变量一次安装、处处运行本地安装Webpack则会添加其为项目中的依赖只能在项目内部使用。这里建议使用本地安装的方式主要有以下两点原因
如果选择全局安装那么在与他人进行项目协作的时候由于每个人系统中的Webpack版本不同可能会导致输出结果不一致。部分依赖于Webpack的插件会调用项目中Webpack的内部模块这种情况下仍然需要在项目本地安装Webpack而如果全局和本地都有则容易造成混淆。
基于以上两点我们选择在工程内部安装Webpack。首先新建一个工程目录从命令行进入该目录并执行npm的初始化命令
npm init # 如果你使用 yarn则为 yarn init此时会要求你输入项目的基本信息因为这里只是为了生成一个示例根据提示操作就好。然后我们会看到目录中生成了一个package.json文件它相当于npm项目的说明书里面记录了项目名称、版本、仓库地址等信息。
接下来执行安装Webpack的命令
npm install webpack webpack-cli -D
# or yarn
yarn add webpack webpack-cli –D这里我们同时安装了webpack以及webpack-cli。webpack是核心模块webpack-cli则是命令行工具在本例中两者都是必需的。
安装结束之后在命令行执行npx webpack -v以及npx webpack-cli -v可显示版本号即证明安装成功。
注意由于我们将Webpack安装在了本地因此无法直接在命令行内使用webpack指令。工程内部只能使用npx webpack 的形式后面会介绍简化该命令的方法。
4、打包第一个应用
现在让我们趁热打铁来打包刚刚的示例工程。如果你是第一次接触Webpack建议按照下面的指引一步步进行操作。代码中不熟悉的地方也不必深究这个示例只是为了让我们直观地认识Webpack的一些特性。
4.1、Hello World
首先我们在工程目录下添加以下几个文件。
index.js
import addContent from ./add-content.js;
document.write(My first Webpack app.br /);
addContent();add-content.js
export default function() {document.write(Hello world!);
}index.html
!DOCTYPE html
html langzh-CN
headmeta charsetUTF-8titleMy first Webpack app./title
/head
bodyscript src./main.js/script
/body
/html然后在控制台输入打包命令
npx webpack --entry./index.js --modedevelopmentWebpack帮我们完成了一项最基本的模块组装工作现在回顾一下刚刚输入的指令。
命令行的第1个参数entry是资源打包的入口。Webpack从这里开始进行模块依赖的查找找到index.js和add-content.js两个模块并通过它们来生成最终产物。
命令行的第2个参数output-filename是输出资源名。你会发现打包完成后工程中出现了一个dist目录其中包含的main.js就是Webpack的打包结果。
最后的参数mode指的是打包模式。Webpack为开发者提供了development、production、none三种模式。当置于development和production模式下时它会自动添加适合当前模式的一系列配置减少了人为的工作量。在开发环境下一般设置为development模式就可以了。
为了验证打包结果可以用浏览器打开index.html。项目中的index.js和content.js现在已经成为bundle.js被页面加载和执行并输出了各自的内容。
4.2、使用npm scripts
从上面的例子不难发现我们每进行一次打包都要输入一段冗长的命令这样做不仅耗时而且容易出错。为了使命令行指令更简洁可以在package.json中添加一个脚本命令。
编辑工程中的package.json文件
……scripts: {build: webpack --entry./index.js --modedevelopment},
……scripts是npm提供的脚本命令功能在这里我们可以直接使用由模块添加的指令比如用webpack取代之前的npx webpack。
为了验证打包结果可以对add-content.js的内容稍加修改
export default function() {document.write(I\m using npm scripts!);
}重新打包这次输入npm命令即可
npm run build打开浏览器验证效果如下图所示
4.3、使用默认目录配置
上面的index.js是放在工程根目录下的而通常情况下我们会分别设置源码目录与资源输出目录。工程源代码放在/src中输出资源放在/dist中。本贴后续的示例也会按照该标准进行目录划分。
在工程中创建一个src目录并将index.js和add-content.js移动到该目录下。对于资源输出目录来说Webpack已经默认是/dist我们不需要做任何改动。
另外需要提到的是Webpack默认的源代码入口就是src/index.js因此现在可以省略entry的配置了。编辑package.json
……scripts: {build: webpack --output-filenamebundle.js --modedevelopment},
……虽然目录命名并不是强制的且Webpack提供了配置项让我们进行更改但还是建议遵循统一的命名规范这样会使得大体结构比较清晰也利于多人协作。
4.4、使用配置文件
为了满足不同应用场景的需求Webpack拥有非常多的配置项以及相对应的命令行参数。我们可以通过Webpack的帮助命令来进行查看
npx webpack –h部分参数如下图所示 从之前我们在package.json中添加的脚本命令来看当项目需要越来越多的配置时就要往命令中添加更多的参数那么到后期维护起来就会相当困难。为了解决这个问题可以把这些参数改为对象的形式专门放在一个配置文件里在Webpack每次打包的时候读取该配置文件即可。
Webpack的默认配置文件为webpack.config.js也可以使用其他文件名需要使用命令行参数指定。现在让我们在工程根目录下创建webpack.config.js并添加如下代码
module.exports {entry: ./src/index.js,output: {filename: main.js,},mode: development,
}上面通过module.exports导出了一个对象也就是打包时被Webpack接收的配置对象。先前在命令行中输入的一大串参数就都要改为key-value的形式放在这个对象中。
目前该对象包含两个关于资源输入输出的属性——entry和output。entry就是我们的资源入口output则是一个包含更多详细配置的对象。在Webpack配置中我们经常会遇到这种层叠的属性关系。这是由于Webpack本身的配置实在太多如果都放在同一级会难以管理因此出现了这种多级配置。当开发者要修改某个配置项时通过层级关系找下来会更加清晰、快捷。
之前的参数–output-filename和–output-path现在都成为output下面的属性。filename和先前一样都是bundle.js不需要改动而path和之前有所区别。Webpack对于output.path的要求是使用绝对路径从系统根目录开始的完整路径之前我们在命令行中为了简洁而使用了相对路径。而在webpack.config.js中我们通过调用Node.js的路径拼装函数path.join将__dirnameNode.js内置全局变量值为当前文件所在的绝对路径与dist输出目录连接起来得到了最终的资源输出路径。
现在我们可以去掉package.json中配置的打包参数了
……scripts: {build: webpack},
……为了验证最终效果我们再对add-content.js的内容稍加修改
export default function() {document.write(I\m using a config file!);
}执行npm run build命令Webpack就会预先读取webpack.config.js然后打包。完成之后我们打开index.html进行验证结果如下图所示
4.5、webpack-dev-server
到这里其实我们已经把Webpack的初始环境配置好了。你可能会发现单纯使用Webpack以及它的命令行工具来进行开发调试的效率并不高。以往只要编辑项目源文件JS、CSS、HTML等刷新页面即可看到效果现在多了一步打包即我们在改完项目源码后要执行npm run build更新bundle.js然后才能刷新页面生效。有没有更简便的方法呢
其实Webpack社区已经为我们提供了一个便捷的本地开发工具——webpack-dev-server。用以下命令进行安装
npm install webpack-dev-server -D安装指令中的-D参数是将webpack-dev-server作为工程的devDependencies开发环境依赖记录在package.json中。这样做是因为webpack-dev-server仅仅在本地开发时才会用到在生产环境中并不需要它所以放在devDependencies中是比较恰当的。假如工程上线时要进行依赖安装就可以通过npm install --onlyprod过滤掉devDependencies中的冗余模块从而加快安装和发布的速度。
为了便捷地启动webpack-dev-server我们在package.json中添加一个dev指令
……scripts: {build: webpack,dev: webpack-dev-server},
……最后我们还需要对webpack-dev-server进行配置。编辑webpack.config.js
module.exports {entry: ./src/index.js,output: {filename: ./main.js,},mode: develpoment,devServer: {publicPath: /dist,},
};可以看到我们在配置中添加了一个devServer对象它是专门用来放webpack-dev-server配置的。webpack-dev-server可以看作一个服务者它的主要工作就是接收浏览器的请求然后将资源返回。当服务启动时它会先让Webpack进行模块打包并将资源准备好在示例中就是bundle.js。当webpack-dev-server接收到浏览器的资源请求时它会首先进行URL地址校验。如果该地址是资源服务地址上面配置的publicPathwebpack-dev-server就会从Webpack的打包结果中寻找该资源并返回给浏览器。反之如果请求地址不属于资源服务地址则直接读取硬盘中的源文件并将其返回。
综上我们可以总结出webpack-dev-server的两大职能
令Webpack进行模块打包并处理打包结果的资源请求。作为普通的Web Server处理静态资源文件请求。
最后在启动服务之前我们还是更改一下add-content.js
export default function() {document.write(I\m using webpack-dev-server!);
}一切就绪执行 npm run dev命令并用浏览器打开http://localhost:8080/可以看到如下图所示的输出结果 这里有一点需要注意。直接用Webpack开发和使用webpack-dev-server有一个很大的区别前者每次都会生成main.js而webpack-dev-server只是将打包结果放在内存中并不会写入实际的bundle.js在每次webpack-dev-server接收到请求时都只是将内存中的打包结果返回给浏览器。
这一点可以通过删除工程中的dist目录来验证你会发现即便dist目录不存在刷新页面后功能仍然是正常的。从开发者的角度来看这其实是符合情理的。在本地开发阶段我们经常会调整目录结构和文件名如果每次都写入实际文件最后就会产生一些没用的垃圾文件还会干扰我们的版本控制因此webpack-dev-server的处理方式显得更加简洁。
webpack-dev-server还有一项很便捷的特性——live-reloading自动刷新。例如我们保持本地服务启动以及浏览器打开的状态到编辑器中去更改add-content.js
export default function() {document.write(This is from live-reloading!);
}此时切回到浏览器你会发现浏览器的内容自动更新了这就是live-reloading的功能。当webpack-dev-server发现工程源文件进行了更新操作后就会自动刷新浏览器显示更新后的内容。该特性可以提升本地开发的效率。在后面我们还会讲到更先进的hot-module-replacement模块热替换甚至不需要刷新浏览器就能获取更新之后的内容。
