webpack 4

 webpack 四大核心概念：

• 入口(entry) // 打包入口
• 输出(output) : 打包后输出的位置配置
• loader  : loader 让 webpack 能够去处理那些非 JavaScript 文件（webpack 自身只理解 JavaScript）。loader 可以将所有类型的文件转换为 webpack 能够处理的有效模块
• 插件(plugins) : 有更强大的功能，比如：打包优化，压缩、代码分割、静态资源处理、环境变量的注入、将所有css的module抽取为单个文件等

1.入口

配置 entry 属性，来指定一个入口起点（单页面）（或多个入口起点（多页面））。默认值为 ./src

1.  
   //单页面入口
2.  
   entry: {
3.  
   main: ‘./path/to/my/entry/file.js‘
4.  
   }
5.  
   //单页面入口简写 chunk名默认为main
6.  
   entry:‘./src/main.js‘, 
7.  
    
8.  
   //多页面入口
9.  
   entry: {
10.  
    pageOne: ‘./src/pageOne/index.js‘,
11.  
    pageTwo: ‘./src/pageTwo/index.js‘,
12.  
    pageThree: ‘./src/pageThree/index.js‘
13.  
    }

webpack4打包应用过程中的提取公共代码部分。相比于webpack3，4.0版本用optimization.splitChunks配置替换了3.0版本的CommonsChunkPlugin插件，splitChunksPlugins只能用于如何抽离公用的代码，也就是抽离公用代码的规则

1.  
   optimization: {
2.  
   splitChunks: {
3.  
   cacheGroups: {
4.  
   // 打包业务中公共代码
5.  
   common: {
6.  
   name: "common",
7.  
   chunks: "all",
8.  
   minSize: 1,
9.  
   priority: 0
10.  
    },
11.  
    // 打包node_modules中的依赖库
12.  
    vendor: {
13.  
    name: "vendor",
14.  
    test: /[\\/]node_modules[\\/]/,
15.  
    chunks: "all",
16.  
    priority: 10
17.  
    }
18.  
    }
19.  
    }
20.  
    }

2.出口

Output用于配置打包输出的文件，包括输出文件的文件名、输出路径、静态资源地址

1.  
   output: {
2.  
   //文件的输出路径，必须是绝对地址,__dirname 总是指向被执行 js 文件的绝对路径，所以当你在
3.  
   // /d1/d2/myscript.js 文件中写了 __dirname， 它的值就是 /d1/d2
4.  
   path:__dirname + ‘/build‘,
5.  
   //配置输出文件名，可添加路径配置，可使用占位符，占位符有以下5种：
6.  
   //name: chunk名，在该例子中就是app和search
7.  
   //hash: 模块标识符的hash值，跟工程内容相关
8.  
   //chunkhash: chunk内容的hash值，只和当前chunk内容相关,可用于缓存设置
9.  
   //id: 模块标识符
10.  
    //query：模块查询参数，取文件名中?后面的内容
11.  
    filename: ‘static/js/[name].[chunkhash:8].js‘,
12.  
    //用于设置非entry入口的chunk的输出文件名，非entry入口的chunk一般在动态引入和抽取公共代码或者进
13.  
    //行代码分割等操作
14.  
    chunkFilename: ‘static/js/[name].[chunkhash:8].chunk.js‘,
15.  
    //用于设置打包过程中产生的静态文件的最终引用地址，静态文件的最终引用地址为output.publicPath +
16.  
    //output.filename
17.  
    publicPath: ‘‘
18.  
    }

resolve 

1.  
   resolve{
2.  
    
3.  
   alias: {
4.  
   ‘root‘: path.resolve(__dirname, ‘../src‘),
5.  
   ‘common‘: path.resolve(__dirname, ‘../src/components/common‘),
6.  
   ‘action‘: path.resolve(__dirname, ‘../src/redux/action‘),
7.  
   ‘workbench‘:path.resolve(__dirname,‘../src/components/workbench‘),
8.  
   ‘prepareAPath‘:path.resolve(__dirname,‘../src/redux/action/workbench/dataprepare‘),
9.  
   ‘updateChart‘: path.resolve(__dirname, ‘../src/redux/action/workbench/visualize-component/UpdateChart.action.js‘),
10.  
    }
11.  
    }
12.  
    //使用
13.  
    import {changeDataSetDefine,fetchDataSetPost} from ‘prepareAPath/MainTemplate.action‘;

3.loaders 

     babel-loader

        将ES2015+的代码转码为ES5的代码

1.  
   modlue: {
2.  
   rules: [
3.  
   {
4.  
   test: /\.js$/,
5.  
   exclude: /(node_modules|bower_components)/,
6.  
   use: ‘babel-loader‘
7.  
   }
8.  
   ]
9.  
   }

   exclude表示不处理的目录，一般node_modules中的第三方js文件不在我们的处理范围内。 

   style-loader

    将css模块以style标签的形式加入到html中

    css-loader

     主要用来解析css中的静态资源，将@import和url()解析为import/require()，解析出的除css以外的静态资源，一般交给url-         loader和file-loader去处理

    sass-loader/less-loader

       将sass/less代码转换为css

       解析一个sass文件，并不只需要一个loader，它需要多个loader串行处理，webpack可以配置多个loader串行处理：

1.  
    
2.  
   module: {
3.  
   rules: [
4.  
   {
5.  
   test: /\.sass$/,
6.  
   use: [ ‘style-loader‘, ‘css-loader‘, ‘postcss-loader‘, ‘sass-loader‘ ]
7.  
   }
8.  
   ]
9.  
   }

 use可配置为一个数组，loader从右往左依次执行，且前一个loader的结果是下一个loader的输入。最后一个loader的输出就是我们最终要的结果。一个sass文件首先经过sass-loader处理，变成css文件，又经过postcss-loader处理，添加浏览器前缀等功能，接着交给css-loader去解析css文件引用的静态变量，最后由style-loader以script标签的形式加入到html中。 

 url-loader/file-loader

 url-loader和file-loader是一对用来处理图片、svg、视频、字体等静态资源文件的loader。一般体积比较小的资源交给url-loader处理，编码为base64字符串，直接嵌入js文件中。体积较大的文件由file-loader处理，直接释放为了一个输出文件。

1.  
    
2.  
    
3.  
   module: {
4.  
   rules: [
5.  
   {
6.  
   test: /\.(png|jpe?g|gif|svg)(\?.*)?$/,
7.  
   loader: ‘url-loader‘,
8.  
   options: {
9.  
   limit: 10000,
10.  
    name: ‘img/[name].[hash:7].[ext]‘
11.  
    }
12.  
    }
13.  
    ]
14.  
    }

一般只配置url-loader即可，在资源超过limit的时候，url-loader会将资源自动交给file-loader处理，并将options内容也传递给file-loader。 

4.插件

  HtmlWebpackPlugin

HtmlWebpackPlugin插件可以用来生成包含你所有打包文件（js和css）的html文件，特别是你在打包文件名配置了hash，就不得不用这个插件了。

1.  
   plugins: [
2.  
   new HtmlWebpackPlugin({
3.  
   template: path.resolve(__dirname, ‘src/index.html‘),
4.  
   filename: ‘static/index.[hash].html‘,
5.  
   inject: true,
6.  
   minify: false,
7.  
   chunks: [‘app‘, ‘vendor‘]
8.  
   })

• template: HtmlWebpackPlugin生成html文件的模板
• filename: 输出的html文件名，规则和output的filename相同
• inject: 是否注入打包的文件，包括js和通过MiniCssExtractPlugin打包输出的css文件，默认为true
• minify: 是否压缩
• chunks: 只注入某些特定chunk的输出文件，在多文件场景下比较有用

 MiniCssExtractPlugin

MiniCssExtractPlugin将一个chunk中的css抽取为一个单独的css文件，如果chunk中不包含css，则不生成文件。且支持按需加载和sourceMap。webpack4新增插件，在webpack4之前是使用ExtractTextWebpackPlugin来做这件事。官方文档总结了MiniCssExtractPlugin相对ExtractTextWebpackPlugin的四个优势：

• 按需异步加载
• 没有重复编译（性能）
• 使用更简单
• 专门为css设计

1.  
   const MiniCssExtractPlugin = require("mini-css-extract-plugin");
2.  
   const devMode = process.env.NODE_ENV !== ‘production‘
3.  
    
4.  
   module.exports = {
5.  
   plugins: [
6.  
   new MiniCssExtractPlugin({
7.  
   // Options similar to the same options in webpackOptions.output
8.  
   // both options are optional
9.  
   filename: "static/css/[name].[contenthash:8].css",
10.  
    chunkFilename: "static/css/[id].[contenthash:8].css"
11.  
    })
12.  
    ],
13.  
    module: {
14.  
    rules: [
15.  
    {
16.  
    test: /\.css$/,
17.  
    use: [
18.  
    devMode ? ‘style-loader‘ : { // MiniCssExtractPlugin目前还没有HMR功能，所以最好只在生成环境使用
19.  
    loader: MiniCssExtractPlugin.loader,
20.  
    options: {
21.  
    publicPath: ‘../‘ // 可单独配置publicPath,默认采用output中的publicPath
22.  
    }
23.  
    },
24.  
    "css-loader"
25.  
    ]
26.  
    }
27.  
    ]
28.  
    }
29.  
    }

CopyWebpackPlugin 

CopyWebpackPlugin用来处理静态文件，可以将文件或者文件夹原封不动地移动到打包目录。

1.  
    
2.  
   const CopyWebpackPlugin = require(‘copy-webpack-plugin‘)
3.  
   plugins: [
4.  
   new CopyWebpackPlugin([
5.  
   {
6.  
   from: ‘public/theme/dark.js‘, to: ‘theme‘
7.  
   },
8.  
   { from: ‘source‘, to: ‘dest‘, toType: ‘dir|file|template‘ }, // 手动设置to的类型，比如设置成dir，即使to设置为a.js,最后也会生成a.js文件夹
9.  
   { from: ‘source‘, to: ‘dest‘, context: ‘/app‘ }, // 基准目录，from相对于context解析
10.  
    { from: ‘source‘, to: ‘dest‘, ignore: [‘*.js‘] }, // ignore, 忽略匹配的文件
11.  
    ‘source‘ // 只有from，to默认为output的path
12.  
    ], {
13.  
    context: ‘/app‘, // 同上
14.  
    ignore: [‘*.js‘], // 同上
15.  
    })
16.  
    ]

CleanWebpackPlugin 

CleanWebpackPlugin用来清除打包目录，主要用于每次重新生成的时候，清除残留文件。尤其文件有hash值的情况下

1.  
    
2.  
   const CleanWebpackPlugin = require(‘clean-webpack-plugin‘);
3.  
   const config = {
4.  
   plugins: [
5.  
   new CleanWebpackPlugin([‘dist‘, ‘bulid/*.js‘], {
6.  
   watch: false, // 是否在--watch（持续增量式监控编译）模式下也清除files然后重新编译，默认
7.  
   //为false
8.  
   exclude: [ ‘files‘, ‘svg‘, ‘css‘ ] // 不删除的子目录和文件
9.  
   }),
10.  
    ]

DefinePlugin 

DefinePlugin用来定义webpack编译期间的全局变量。我们可以根据这些变量，来做不同的动作。最典型的就是可以区分开发环境和生产环境，比如在开发环境打印各种警告、错误，在生产环境去掉这些跟业务无关的代码。

DefinePlugin的参数是一个对象，键名是一个标识符，或者用.隔开的多级标识符，

1.  
   new webpack.DefinePlugin({
2.  
   ‘process.env.NODE_ENV‘: JSON.stringify(‘production‘),
3.  
   PRODUCTION: JSON.stringify(true),
4.  
   VERSION: JSON.stringify(‘5fa3b9‘),
5.  
   BROWSER_SUPPORTS_HTML5: true,
6.  
   TWO: ‘1+1‘
7.  
   });

DefinePlugin的原理很简单，只是在编译过程中遇到这些定义好的键名，就用键值做简单的文本替换。所以，你如果想给全局变量赋一个字符串，需要这样写‘"production"‘,一般使用JSON.stringify来转一下。 

ProvidePlugin

1.  
   // 全局暴露统一入口
2.  
   new webpack.ProvidePlugin({
3.  
   $: "jquery"
4.  
   }),

uglifyjsWebpackPlugin  

 js压缩插件，webpack4 新增了webpack4新增了mode配置。webpack会根据mode值自动做不同的优化

webpack4 只需要在script里面写成 "build": "webpack --mode production", 就自动压缩了

    代码分割

  代码分割可以把代码按照一定的逻辑分割，用来做按需加载或者并行加载，以减少加载时间。在webpack中，主要有以下3中方   式，实现代码分割：

• Entry Points: 手动在entry入口配置处配置多个入口
• SplitChunks: webpack4默认带这个优化插件，用于抽取不同chunk的公共部分，或者直接代码分割
• Dynamic Imports: 动态加载，在函数中使用import()语法，webpack使用SplitChunks将import()加载的module分割为一个单独的chunk，并在函数执行时加载该chunk对应的js文件。

   1.SplitChunks

webpack4打包应用过程中的提取公共代码部分。相比于webpack3，4.0版本用optimization.splitChunks配置替换了3.0版本的CommonsChunkPlugin插件，splitChunksPlugins只能用于如何抽离公用的代码，也就是抽离公用代码的规则。

splitChunks默认只对按需加载的chunk起作用，会自动将import()引入的module分割为单独chunk，但是需要满足以下条件：

• 新chunk中的模块被共享或者来自node_modules
• 新chunk必须大于30kb
• 按需加载的chunks并行加载的数量要小于等于5
• 入口文件的并行加载的请求应该小于等于3

在执行后两个原则的时候，体积大的chunk被优先生成。

1.  
   optimization: {
2.  
   splitChunks: {
3.  
   cacheGroups: {
4.  
   // 打包业务中公共代码
5.  
   common: {
6.  
   name: "common",
7.  
   chunks: "all",
8.  
   minSize: 1,
9.  
   priority: 0
10.  
    },
11.  
    // 打包node_modules中的依赖库
12.  
    vendor: {
13.  
    name: "vendor",
14.  
    test: /[\\/]node_modules[\\/]/,
15.  
    chunks: "all",
16.  
    priority: 10
17.  
    }
18.  
    }
19.  
    }
20.  
    }

splitChunks的默认配置如下 

1.  
   optimization: {
2.  
   splitChunks: {
3.  
   chunks: ‘async‘,
4.  
   minSize: 30000, // chunk只有超过这个大小才会被分割
5.  
   maxSize: 0, // 大于这个体积的chunk会被自动分割为更小的chunk
6.  
   minChunks: 1, // 一个模块被共享的chunk数量大于minChunks时，才会被分割出来
7.  
   maxAsyncRequests: 5, // 按需加载最大的并行数
8.  
   maxInitialRequests: 3, // 初始加载最大的并行数
9.  
   automaticNameDelimiter: ‘~‘, // name为true时，新chunk的文件名由cacheGroups的key加上chunks属性的一些信息生成，automaticNameDelimiter是分隔符
10.  
    name: true,
11.  
    cacheGroups: { // 配置拆分规则，会继承splitChunks所有的配置项，所有splitChunks配置项都可以在这里重写覆盖，test、prioprity、reuseExistingChunk是cacheGroups独有的属性
12.  
    vendors: {
13.  
    test: /[\\/]node_modules[\\/]/, // 模块匹配规则，可以是正则表达式或者函数，不写默认选择所有模块
14.  
    priority: -10 // 优先级，当同一个模块同时包含在不同cacheGroup中，该模块将被划分到优先级高的组中
15.  
    },
16.  
    default: {
17.  
    minChunks: 2,
18.  
    priority: -20,
19.  
    reuseExistingChunk: true // 如果该chunk包含的modules都已经另一个被分割的chunk中存在，那么直接引用已存在的chunk，不会再重新产生一个
20.  
    }
21.  
    }
22.  
    }
23.  
    }

splitChunks的chunks属性表示作用的chunk范围。chunks可以是一个函数，完全由开发者控制；也可以是一个字符串，字符串一共有3个值：

• initial,表示只作用于入口chunk
• async，表示只作用于动态引入的异步chunk
• all，所有chunk

name

name属性表示最后生成chunk的文件名，有以下3种类型取值：

• boolean，设置为true，则会根据cacheGroup的key和chunks属性的信息自动生成
• string，如果设置在splitChunks下，那所有chunk设置为相同的名称，这会造成不同的chunk合成为一个chunk,当然你可以设置在cacheGroup下
• function，完全由开发者控制

webpack在打包的时候会将import的组件全部打包进去，如果利用react-route（4以前）来实现路由机制的，可以采用它提供的getComponent来动态获取组件，这样就实现了按需加载，在react-router 3中，可以使用Route组件中getComponent这个API来进行代码拆分。getComponent是异步的，只有在路由匹配时才会调用。

1.  
   const datasource = (location, cb) => {
2.  
   require.ensure([], require => {
3.  
   cb(null, require(‘../components/workbench/datasource/index‘).default)
4.  
   }, error => {
5.  
   console.log(‘failed‘);
6.  
   },‘datasource‘)
7.  
   };
8.  
   <Route path =‘datasource‘ getComponent ={datasource}>
9.  
   //第一个参数dependencies是一个数组，代表了当前require进来的模块的一些依赖；
10.  
    //第二个参数callback就是一个回调函数。其中需要注意的是，这个回调函数有一个参数require，通过这
11.  
    //个require就可以在回调函数内动态引入其他模块。值得注意的是，虽然这个require是回调函数的参数，
12.  
    //理论上可以换其他名称，但是实际上是不能换的，否则webpack就无法静态分析的时候处理它；
13.  
    //第三个参数errorCallback比较好理解，就是处理error的回调；
14.  
    //第四个参数chunkName则是指定打包的chunk名称。
15.  
     

Vue项目中路由设置一般会引入组件，然后使用。但是这会造成项目一次加载很多组件，影响响应时间。解决这个问题就可以使用路由的懒加载,有三种方法可以实现：

1.  
    export default new Router({
2.  
     routes: [
3.  
       {
4.  
         path: ‘/‘,
5.  
         name: ‘HelloWorld‘,
6.  
         component:r=>require.ensure([],()=>r(require(‘@/components/HelloWorld‘)),‘HelloWorld‘)  // 1.
7.  
         // component:()=>import(‘@/components/HelloWorld‘/*webpackChunkName: "helloworld2"*/)   // 2.
8.  
         // component:resolve=>require([‘@/components/HelloWorld‘],resolve)                      // 3.
9.  
       }
10.  
      ]
11.  
    })

打包结果

1.    异步加载的会单独打包成单独的chunk(多个文件组成的一个代码块，例如把一个可执行模块和它所有依赖的模块组合和一  个 chunk ) 
2.    公共的业务代码以及第三方moudle打包成单独的chunk使用插件(SplitChunks)

bundle 与 chunk 的区别

1. 打包过程中被操作的模块文件叫做chunk,例如异步加载一个模块就是一个chunk
2. bundle是最后打包后的文件,最终文件可以和chunk长的一模一样,但是大部分情况下他是多个chunk的集合

.map文件

.map 文件是什么：

Webpack打包生成的.map后缀文件，使得我们的开发调试更加方便，它能帮助我们链接到断点对应的源代码的位置进行调试。

.map文件的作用：

项目打包后，代码都是经过压缩加密的，如果运行时报错，输出的错误信息无法准确得知是哪里的代码报错。 有了map就可以像未加密的代码一样，准确的输出是哪一行哪一列有错（方便调试）。

打包流程

webpack知识分享

原文：https://www.cnblogs.com/plBlog/p/11431371.html