概念
来看一下官网对webpack的定义:
实质上,webpack 是一个古代 JavaScript 应用程序的动态模块打包器(module bundler)。当 webpack 解决应用程序时,它会递归地构建一个依赖关系图(dependency graph),其中蕴含应用程序须要的每个模块,而后将所有这些模块打包成一个或多个bundle。
首先webpack是一个动态模块打包器,所谓的动态模块,包含脚本、样式表和图片等等;webpack打包时首先遍历所有的动态资源,依据资源的援用,构建出一个依赖关系图,而后再将模块划分,打包出一个或多个bundle。再次白piao一下官网的图,活泼的形容了这个过程:
提到webpack,就不得不提webpack的四个外围概念
- 入口(entry):批示 webpack 应该应用哪个模块,来作为构建其外部依赖图的开始
- 输入(output):在哪里输入它所创立的 bundles
- loader:让 webpack 可能去解决那些非 JavaScript 文件
- 插件(plugins):用于执行范畴更广的工作
你的第一个打包器
咱们首先在全局装置webpack:
npm install webpack webpack-cli –g
webpack能够不应用配置文件,间接通过命令行构建,用法如下:
webpack <entry> [<entry>] -o <output>
这里的entry和output就对应了上述概念中的入口和输出,咱们来新建一个入口文件:
//demo1/index.jsvar a = 1console.log(a)document.write('hello webpack')
有了入口文件咱们还须要通过命令行定义一下输出门路dist/bundle.js:
webpack index.js -o dist/bundle.js
这样webpack就会在dist目录生成打包后的文件。
咱们也能够在我的项目目录新建一个html引入打包后的bundle.js文件查看成果。
配置文件
命令行的打包形式仅限于简略的我的项目,如果咱们的我的项目较为简单,有多个入口,咱们不可能每次打包都把入口记下来;因而个别我的项目中都应用配置文件来进行打包;配置文件的命令形式如下:
webpack [--config webpack.config.js]
配置文件默认的名称就是webpack.config.js
,一个我的项目中常常会有多套配置文件,咱们能够针对不同环境配置不同的文件,通过--config
来进行切换:
//生产环境配置webpack --config webpack.prod.config.js//开发环境配置webpack --config webpack.dev.config.js
相干webpack视频解说:进入学习
多种配置类型
config配置文件通过module.exports
导出一个配置对象:
//webpack.config.jsvar path = require('path');module.exports = { mode: 'development', //入口文件 entry: './index.js', //输入目录 output: { path: path.resolve(__dirname, 'dist'), filename: 'bundle.js' }};
除了导出为对象,还能够导出为一个函数,函数中会带入命令行中传入的环境变量等参数,这样能够更不便的对环境变量进行配置;比方咱们在打包线上正式环境和线上开发环境能够通过env
进行辨别:
var path = require('path');//env:环境对象module.exports = function(env, argv){ return { //其余配置 entry: './index.js', output: {} }};
另外还能够导出为一个Promise,用于异步加载配置,比方能够动静加载入口文件:
module.exports = () => { return new Promise((resolve, reject)=>{ setTimeout(()=>{ resolve({ entry: './index.js', output: {} }) }, 5000) })}
入口
正如在下面提到的,入口是整个依赖关系的终点入口;咱们罕用的单入口配置是一个页面的入口:
module.exports = { entry: './index.js',}
它是上面的简写:
module.exports = { entry: { main: './index.js' },}
然而咱们一个页面可能不止一个模块,因而须要将多个依赖文件一起注入,这时就须要用到数组了,代码在demo2中:
module.exports = { entry: [ //轮播图模块 './src/banner.js', //主模块 './src/index.js', //底部模块 './src/foot.js' ],}
有时候咱们一个我的项目可能有不止一个页面,须要将多个页面离开打包,entry反对传入对象的模式,代码在demo3中:
//demo3module.exports = { entry: { home: './src/home.js', list: './src/list.js', detail: ['./src/detail.js', './src/common.js'], },}
这样webpack就会构建三个不同的依赖关系。
输入
output
选项用来管制webpack如何输出编译后的文件模块;尽管能够有多个entry,然而只能配置一个output
:
module.exports = { entry: './src/index.js', output: { path: path.resolve(__dirname, 'dist'), filename: 'bundle.js', //CDN地址 publicPath: '/', },}
这里咱们配置了一个单入口,输入也就是bundle.js;然而如果存在多入口的模式就行不通了,webpack会提醒Conflict: Multiple chunks emit assets to the same filename
,即多个文件资源有雷同的文件名称;webpack提供了占位符
来确保每一个输入的文件都有惟一的名称:
module.exports = { entry: { home: './src/home.js', list: './src/list.js', detail: ['./src/detail.js', './src/common.js'], }, output: { path: path.resolve(__dirname, 'dist'), filename: '[name].bundle.js', },}
这样webpack打包进去的文件就会依照入口文件的名称来进行别离打包生成三个不同的bundle文件;还有以下不同的占位符字符串:
占位符 | 形容 |
---|---|
[hash] | 模块标识符(module identifier)的 hash |
[chunkhash] | chunk 内容的 hash |
[name] | 模块名称 |
[id] | 模块标识符 |
[query] | 模块的 query,例如,文件名 ? 前面的字符串 |
在这里引入Module、Chunk和Bundle的概念,下面代码中也常常会看到有这两个名词的呈现,那么他们三者到底有什么区别呢?首先咱们发现module是经常出现在咱们的代码中,比方module.exports;而Chunk常常和entry一起呈现,Bundle总是和output一起呈现。
- module:咱们写的源码,无论是commonjs还是amdjs,都能够了解为一个个的module
- chunk:当咱们写的module源文件传到webpack进行打包时,webpack会依据文件援用关系生成chunk文件,webpack 会对这些chunk文件进行一些操作
- bundle:webpack解决好chunk文件后,最初会输入bundle文件,这个bundle文件蕴含了通过加载和编译的最终源文件,所以它能够间接在浏览器中运行。
咱们通过上面一张图更深刻的了解这三个概念:
总结:
module,chunk 和 bundle 其实就是同一份逻辑代码在不同转换场景下的取了三个名字:咱们间接写进去的是module,webpack解决时是chunk,最初生成浏览器能够间接运行的bundle。
hash、chunkhash、contenthash
了解了chunk的概念,置信下面表中chunkhash和hash的区别也很容易了解了;
- hash:是跟整个我的项目的构建相干,只有我的项目里有文件更改,整个我的项目构建的hash值都会更改,并且全副文件都共用雷同的hash值。
- chunkhash:跟入口文件的构建无关,依据入口文件构建对应的chunk,生成每个chunk对应的hash;入口文件更改,对应chunk的hash值会更改。
- contenthash:跟文件内容自身相干,依据文件内容创立出惟一hash,也就是说文件内容更改,hash就更改。
模式
在webpack2和webpack3中咱们须要手动退出插件来进行代码的压缩、环境变量的定义,还须要留神环境的判断,非常的繁琐;在webpack4中间接提供了模式这一配置,开箱即可用;如果疏忽配置,webpack还会收回正告。
module.exports = { mode: 'development',};//相当于module.exports = { devtool:'eval', plugins: [ new webpack.NamedModulesPlugin(), new webpack.NamedChunksPlugin(), new webpack.DefinePlugin({ "process.env.NODE_ENV": JSON.stringify("development") }) ]}
开发模式是通知webpack,我当初是开发状态,也就是打包进去的内容要对开发敌对,便于代码调试以及实现浏览器实时更新。
module.exports = { mode: 'production',};//相当于module.exports = { plugins: [ new UglifyJsPlugin(/*...*/), new webpack.DefinePlugin({ "process.env.NODE_ENV": JSON.stringify("production") }), new webpack.optimize.ModuleConcatenationPlugin(), new webpack.NoEmitOnErrorsPlugin() ]}
生产模式不必对开发敌对,只须要关注打包的性能和生成更小体积的bundle。看到这里用到了很多Plugin,不必慌,上面咱们会一一解释他们的作用。
置信很多童鞋都曾有过疑难,为什么这边DefinePlugin定义环境变量的时候要用JSON.stringify("production")
,间接用"production"
不是更简略吗?
咱们首先来看下JSON.stringify("production")
生成了什么;运行后果是""production""
,留神这里,并不是你眼睛花了或者屏幕上有小黑点,后果的确比"production"
多嵌套了一层引号。
咱们能够简略的把DefinePlugin这个插件了解为将代码里的所有process.env.NODE_ENV
替换为字符串中的内容
。如果咱们在代码中有如下判断环境的代码:
//webpack.config.jsmodule.exports = { plugins: [ new webpack.DefinePlugin({ "process.env.NODE_ENV": "production" }), ]}//src/index.jsif (process.env.NODE_ENV === 'production') { console.log('production');}
这样生成进去的代码就会编译成这样:
//dist/bundle.js//代码中并没有定义production变量if (production === 'production') { console.log('production');}
然而咱们代码中可能并没有定义production
变量,因而会导致代码间接报错,所以咱们须要通过JSON.stringify来包裹一层:
//webpack.config.jsmodule.exports = { plugins: [ new webpack.DefinePlugin({ //"process.env.NODE_ENV": JSON.stringify("production") //相当于 "process.env.NODE_ENV": '"production"' }), ]}//dist/bundle.jsif ("production" === 'production') { console.log('production');}
这样编译进去的代码就没有问题了。
主动生成页面
在下面的代码中咱们发现都是手动来生成index.html,而后引入打包后的bundle文件,然而这样太过繁琐,而且如果生成的bundle文件引入了hash值,每次生成的文件名称不一样,因而咱们须要一个主动生成html的插件;首先咱们须要装置这个插件:
npm install --save-dev html-webpack-plugin
在demo3中,咱们生成了三个不同的bundle.js,咱们心愿在三个不同的页面能别离引入这三个文件,如下批改config文件:
module.exports = { //省略其余代码 plugins: [ new HtmlWebpackPlugin({ //援用的模板文件 template: './index.html', //生成的html名称 filename: 'home.html', chunks: ['home'] }), new HtmlWebpackPlugin({ template: './index.html', filename: 'list.html', chunks: ['list'] }), new HtmlWebpackPlugin({ template: './index.html', filename: 'detail.html', chunks: ['detail'] }), ]}
咱们以index.html作为模板文件,生成home、list、detail三个不同的页面,并且通过chunks别离引入不同的bundle;如果这里不写chunks,每个页面就会引入所有生成进去的bundle。
html-webpack-plugin还反对以下字段:
new HtmlWebpackPlugin({ template: './index.html', filename: 'all.html', //页面注入title title: 'html webpack plugin title', //默认引入所有的chunks链接 chunks: 'all', //注入页面地位 inject: true, //启用hash hash: true, favicon: '', //插入meta标签 meta: { 'viewport': 'width=device-width, initial-scale=1.0' }, minify: { //革除script标签引号 removeAttributeQuotes: true, //革除html中的正文 removeComments: true, //革除html中的空格、换行符 //将html压缩成一行 collapseWhitespace: false, //压缩html的行内款式成一行 minifyCSS: true, //革除内容为空的元素(慎用) removeEmptyElements: false, //革除style和link标签的type属性 removeStyleLinkTypeAttributes: false }}),
下面设置title后须要在模板文件中设置模板字符串:
<title><%= htmlWebpackPlugin.options.title %></title>
loader
loader用于对模块module的源码进行转换,默认webpack只能辨认commonjs代码,然而咱们在代码中会引入比方vue、ts、less等文件,webpack就解决不过去了;loader拓展了webpack解决多种文件类型的能力,将这些文件转换成浏览器可能渲染的js、css。
module.rules
容许咱们配置多个loader,可能很清晰的看出以后文件类型利用了哪些loader,loader的代码均在demo4中。
{ module: { rules: [ { test: /\.js$/, use: { loader: 'babel-loader', options: {} } }, { test: /\.css$/, use: [ { loader: 'style-loader' }, { loader: 'css-loader' } ] }, ] }}
咱们能够看到rules属性值是一个数组,每个数组对象示意了不同的匹配规定;test属性时一个正则表达式,匹配不同的文件后缀;use示意匹配了这个文件后调用什么loader来解决,当有多个loader的时候,use就须要用到数组。
多个loader反对链式传递,可能对资源进行流水线解决,上一个loader解决的返回值传递给下一个loader;loader解决有一个优先级,从右到左,从下到上;在下面demo中对css的解决就听从了这个优先级,css-loader先解决,解决好了再给style-loader;因而咱们写loader的时候也要留神前后程序。
css-loader和style-loader
css-loader和style-loader从名称看起来性能很类似,然而两者的性能有着很大的区别,然而他们常常会成对应用;装置办法:
npm i -D css-loader style-loader
css-loader用来解释@import和url();style-loader用来将css-loader生成的样式表通过<style>标签
,插入到页面中去。
/* /src/head.css */.head{ display: flex; background: #666;}/* /src/foot.css */.foot{ background: #ccc;}/* /src/index.css */@import './head.css';@import './foot.css';.wrap { background: #999;}
而后在入口文件中将index.css引入,就能看到打包的成果,页面中插入了三个style标签,代码在demo4:
sass-loader和less-loader
这两个loader看名字大家也能猜到了,就是用来解决sass和less款式的。装置办法:
npm i -D sass-loader less-loader node-sass
在config中进行配置,代码在demo4:
{ //其余配置 rules: { test: /\.scss$/, use: [{ loader: 'style-loader' }, { loader: 'css-loader' },{ loader: 'sass-loader' }] },{ test: /\.less$/, use: [{ loader: 'style-loader' }, { loader: 'css-loader' },{ loader: 'less-loader' }] }}
postcss-loader
都0202年了,小伙伴必定不想一个一个的手动增加-moz、-ms、-webkit等浏览器公有前缀;postcss提供了很多对款式的扩大性能;啥都不说,先装置起来:
npm i -D postcss-loader
老规矩,还是在config中进行配置:
rules: [{ test: /\.scss$/, use: [{ loader: 'style-loader' }, { loader: 'css-loader' }, { loader: 'postcss-loader' },{ loader: 'sass-loader' }]},{ test: /\.less$/, use: [{ loader: 'style-loader' }, { loader: 'css-loader' }, { loader: 'postcss-loader' },{ loader: 'less-loader' }]}]
正当咱们灰溜溜的打包看成果时,发现款式还是老样子,并没有什么扭转。
这是因为postcss次要性能只有两个:第一就是把css解析成JS能够操作的形象语法树AST,第二就是调用插件来解决AST并失去后果;所以postcss个别都是通过插件来解决css,并不会间接解决,所以咱们须要先装置一些插件:
npm i -D autoprefixer postcss-plugins-px2rem cssnano
在我的项目根目录新建一个.browserslistrc
文件。
> 0.25%last 2 versions
咱们将postcss的配置独自提取到我的项目根目录下的postcss.config.js
:
module.exports = { plugins: [ //主动增加前缀 require('autoprefixer'), //px转为rem,利用于挪动端 require('postcss-plugins-px2rem')({ remUnit: 75 }), //优化合并css require('cssnano'), ]}
有了autoprefixer
插件,咱们打包后的css就主动加上了前缀。
babel-loader
兼容低版本浏览器的痛置信很多童鞋都经验过,写完代码发现自己的js代码不能运行在IE10或者IE11上,而后尝试着引入各种polyfill;babel的呈现给咱们提供了便当,将高版本的ES6甚至ES7转为ES5;咱们首先装置babel所须要的依赖:
npm i -D babel-loader @babel/core @babel/preset-env @babel/plugin-transform-runtimenpm i -S @babel/runtime
而后在config增加loader对js进行解决:
{ //省略其余配置 rules: [{ test: /\.js/, use: { loader: 'babel-loader' } }]}
同样的,咱们把babel的配置提取到根目录,新建一个.babelrc
文件:
{ "presets": [ "@babel/preset-env" ], "plugins": [ "@babel/plugin-transform-runtime" ]}
咱们能够在index.js中尝试写一些es6的语法,看到代码会被转译成es5,代码在demo4中。因为babel-loader的转译速度很慢,在前面咱们退出了工夫插件后能够看到每个loader的耗时,babel-loader是最耗时间;因而咱们要尽可能少的应用babel来转译文件,咱们对config进行改良,
{ //省略其余配置 rules: [{ test: /\.js$/, use: { loader: 'babel-loader' }, // exclude: /node_modules/, include: [path.resolve(__dirname, 'src')] }]}
正则上应用$
来进行准确匹配,通过exclude将node_modules中的文件进行排除,include将只匹配src中的文件;能够看进去include的范畴比exclude更放大更准确,因而也是举荐应用include。
file-loader和url-loader
file-loader和url-loader都是用来解决图片、字体图标等文件;url-loader工作时候两种状况:当文件大小小于limit参数,url-loader将文件转为base-64编码,用于缩小http申请;当文件大小大于limit参数时,调用file-loader进行解决;因而咱们优先应用url-loader,首先还是进行装置,装置url-loader之前还须要把file-loader先装置:
npm i file-loader url-loader -D
接下来还是批改config:
{ //省略其余配置 rules: [{ test: /\.(png|jpg|gif|jpeg|webp|svg|eot|ttf|woff|woff2)$/, use: { loader: 'url-loader', options: { //10k limit: 10240, //生成资源名称 name: '[name].[hash:8].[ext]', //生成资源的门路 outputPath: 'imgs/' }, exclude: /node_modules/, } }]}
咱们在css中给body增加一个小于10k的居中背景图片:
body{ width: 100vw; height: 100vh; background: url(./bg.png) no-repeat; background-size: 400px 400px; background-position: center center;}
打包后查看body的款式能够发现图片曾经被替换成base64格局的url了,代码在demo4。
html-withimg-loader
如果咱们在页面上援用一个图片,会发现打包后的html还是援用了src目录下的图片,这样显著是谬误的,因而咱们还须要一个插件对html援用的图片进行解决:
npm i -D html-withimg-loader
老样子还是在config中对html进行配置:
{ //省略其余配置 rules: [{ test: /\.(htm|html)$/, use: { loader: 'html-withimg-loader' } }]}
然鹅,关上页面发现却是这样的:
这是因为在url-loader中把每个图片作为一个模块来解决了,咱们还须要去url-loader中批改:
use: { loader: 'url-loader', options: { //10k limit: 10240, esModule: false }}
这样咱们在页面上的图片援用也被批改了,代码在demo4中。
注
html-withimg-loader会导致html-webpack-plugin插件注入title的模板字符串<%= htmlWebpackPlugin.options.title %>
生效,一成不变的展现在页面上;因而,如果咱们想保留两者的性能须要在配置config中把html-withimg-loader删除并且通过上面的形式来援用图片:
<img src="<%=require('./src/bg1.png') %>" alt="" srcset="">
vue-loader
最初说一下一个比拟非凡的vue-loader,看名字就晓得是用来解决vue文件的。
npm i -D vue-loader vue-template-compilernpm i -S vue
咱们首先来创立一个vue文件,具体代码在demo5中:
//src/App.vue<template> <div id="app"> <div class="box" @click="tap">{{title}}</div> </div></template><script>export default { name: 'app', data(){ return { title: 'app实例' } }, methods: { tap(){ this.title = this.title.split('').reverse().join('') } }}</script><style>#app{ font-size: 16px; background: #ccc;}</style>
而后在webpack的入口文件中援用它:
//src/main.jsimport Vue from 'vue'import App from './App.vue'new Vue({ render: h => h(App)}).$mount('#app')
不过vue-loader和其余loader不太一样,除了将它和.vue
文件绑定之外,还须要引入它的一个插件:
const VueLoaderPlugin = require('vue-loader/lib/plugin')module.exports = { module: { rules: [ //省略其余loader { test: /\.vue$/, loader: 'vue-loader' }] }, plugins: [ new VueLoaderPlugin(), ]}
这样咱们就能欢快的在代码中写vue了。
搭建开发环境
在下面的demo中咱们都是通过命令行打包生成dist文件,而后间接关上html或者通过static-server
来查看页面的;然而开发中咱们写完代码每次都来打包会重大影响开发的效率,咱们冀望的是写完代码后立刻就可能看到页面的成果;webpack-dev-server就很好的提供了一个简略的web服务器,可能实时从新加载。
首先在咱们的我的项目中装置依赖:
npm i -D webpack webpack-dev-server
webpack-dev-server的用法和wepack一样,只不过他会额定启动一个express的服务器。咱们在我的项目中新建一个webpack.dev.config.js
配置文件,独自对开发环境进行一个配置,相干代码在demo6中:
module.exports = { //省略其余配置 devServer: { //启动服务器端口 port: 9000, //默认是localhost,只能本地拜访 host: "0.0.0.0", //主动关上浏览器 open: false, //启用模块热替换 hot: true, //启用gzip压缩 compress: true }, plugins: [ //热更新插件 new webpack.HotModuleReplacementPlugin({ }) ]}
通过命令行webpack-dev-server
来启动服务器,启动后咱们发现根目录并没有生成任何文件,因为webpack打包到了内存中,不生成文件的起因在于拜访内存中的代码比拜访文件中的代码更快。
咱们在public/index.html的页面上有时候会援用一些本地的动态文件,间接关上页面的会发现这些动态文件的援用生效了,咱们能够批改server的工作目录,同时指定多个动态资源的目录:
contentBase: [ path.join(__dirname, "public"), path.join(__dirname, "assets")]
热更新(Hot Module Replacemen简称HMR)是在对代码进行批改并保留之后,webpack对代码从新打包,并且将新的模块发送到浏览器端,浏览器通过新的模块替换老的模块,这样就能在不刷新浏览器的前提下实现页面的更新。
能够看出浏览器和webpack-dev-server之间通过一个websock进行连贯,初始化的时候client端保留了一个打包后的hash值;每次更新时server监听文件改变,生成一个最新的hash值再次通过websocket推送给client端,client端比照两次hash值后向服务器发动申请返回更新后的模块文件进行替换。
咱们点击源码旁的行数看一下编译后的源码是什么样的:
发现跟咱们的源码差距还是挺大的,原本是一个简略add函数,通过webpack的模块封装,曾经很难了解原来代码的含意了,因而,咱们须要将编译后的代码映射回源码;devtool中不同的配置有不同的成果和速度,综合性能和品质后,咱们个别在开发环境应用cheap-module-eval-source-map
,在生产环境应用source-map
。
module.exports = { devtool: 'cheap-module-eval-source-map', //其余配置}
其余各模式的比照:
plugins
在下面咱们也介绍了DefinePlugin、HtmlWebpackPlugin等很多插件,咱们发现这些插件都可能不同水平的影响着webpack的构建过程,上面还有一些罕用的插件,plugins相干代码在demo7中。
clean-webpack-plugin
clean-webpack-plugin用于在打包前清理上一次我的项目生成的bundle文件,它会依据output.path主动清理文件夹;这个插件在生产环境用的频率十分高,因为生产环境常常会通过hash生成很多bundle文件,如果不进行清理的话每次都会生成新的,导致文件夹十分宏大;这个插件装置应用十分不便:
npm i -D clean-webpack-plugin
装置后咱们在config中配置一下就能够了:
const { CleanWebpackPlugin } = require('clean-webpack-plugin');module.exports = { //其余配置 plugins: [ new CleanWebpackPlugin(), new HtmlWebpackPlugin({ template: './public/index.html', filename: 'index.html', }) ]}
mini-css-extract-plugin
咱们之前的款式都是通过style-loader插入到页面中去,然而生产环境须要独自抽离款式文件,mini-css-extract-plugin就能够帮我从js中剥离款式:
npm i -D mini-css-extract-plugin
咱们在开发环境应用style-loader,生产环境应用mini-css-extract-plugin:
const MiniCssExtractPlugin = require('mini-css-extract-plugin');module.exports = { //其余配置 module: { rules: [ { test: /\.less/, use: [{ loader: isDev ? 'style-loader' : MiniCssExtractPlugin.loader },{ loader: 'css-loader' },{ loader: 'less-loader' }] } ] }, plugins: [ new MiniCssExtractPlugin({ filename: "[name].[hash:8].css", }) ]}
引入loader后,咱们还须要配置plugin,提取的css同样反对output.filename
中的占位符字符串。
optimize-css-assets-webpack-plugin
咱们能够发现尽管配置了production
模式,打包进去的js压缩了,然而打包进去的css确没有压缩;在生产环境咱们须要对css进行一下压缩:
npm i optimize-css-assets-webpack-plugin -D
而后也是引入插件:
const OptimizeCSSAssetsPlugin = require('optimize-css-assets-webpack-plugin');module.exports = { //其余配置 plugins: [ new OptimizeCSSAssetsPlugin(), ]}
copy-webpack-plugin
和demo6中一样,咱们在public/index.html中引入了动态资源,然而打包的时候webpack并不会帮咱们拷贝到dist目录,因而copy-webpack-plugin就能够很好地帮我做拷贝的工作了
npm i -D copy-webpack-plugin
在config中配置咱们须要拷贝的源门路和指标门路:
const CopyWebpackPlugin = require('copy-webpack-plugin');module.exports = { plugins: [ new CopyWebpackPlugin({ patterns: [ { from: 'public/js/*.js', to: path.resolve(__dirname, 'dist', 'js'), flatten: true, } ] }), ]}
ProvidePlugin
ProvidePlugin能够很快的帮咱们加载想要引入的模块,而不必require。个别咱们加载jQuery须要先把它import:
import $ from 'jquery'$('.box').html('box')
然而咱们在config中配置ProvidePlugin插件后可能不必import,间接应用$
:
module.exports = { plugins: [ new webpack.ProvidePlugin({ $: 'jquery', jQuery: 'jquery' }), ]}
然而如果在我的项目中引入了太多模块并且没有require会让人摸不着头脑,因而倡议加载一些常见的比方jQuery、vue、lodash等。
loader和plugin的区别
介绍了这么多loader和plugin,咱们来回顾一下他们两者的区别:
loader:因为webpack只能辨认js,loader相当于翻译官的角色,帮忙webpack对其余类型的资源进行转译的预处理工作。
plugins:plugins扩大了webpack的性能,在webpack运行时会播送很多事件,plugin能够监听这些事件,而后通过webpack提供的API来扭转输入后果。