webpack配置详解

1.使用模式：

(1).CLI模式：也就是命令行用户界面。例如：

webpack example1.1.js bundle1.1.js

如果我们直接执行webpack，不加任何参数（且当前目录不存在配置文件），则会显示webpack的帮助信息，里面有非常多的参数可用。

事实上，除了我们前面这种出于演示的目的直接在命令行中写参数之外，大部分生产环境下使用时都会需要加上非常多的参数，导致整个命令非常长，既不利于记忆编写，也不利于传播交接等。

因此，一般会将配置项写在同目录的webpack.config.js中，然后执行webpack即可，webpack会从该配置文件中读取参数，此时不需要在命令行中传入任何参数。

# 执行时webpack会去寻找当前目录下的webpack.config.js当作配置文件使用
webpack

# 也可以用参数-c指定配置文件
webpack -c mycofnig.js

配置文件webpack.config.js的写法则是：

module.exports = {
    // 配置项
};

(2).API模式：API则是指将webpack作为Node.js模块使用，例如：

webpack({
    // 配置项
    entry:'main.js',
    ...
},callback);

2.配置文件：

(1).核心概念：

entry（入口起点）:

指示 webpack 应该使用哪个模块，来作为构建其内部依赖图的开始。进入入口起点后，webpack 会找出有哪些模块和库是入口起点（直接和间接）依赖的。通过配置 entry 属性，来指定一个入口起点（或多个入口起点）。

output（出口）:

告诉 webpack 在哪里输出它所创建的 bundles，以及如何命名这些文件。你可以通过在配置中指定一个 output 字段，来配置这些处理过程。

loader（loader应该定义在module.rules中而不是rules中！）: 

loader 让 webpack 能够去处理那些非 JavaScript 文件（webpack 自身只理解 JavaScript）。loader 可以将所有类型的文件转换为 webpack 能够处理的有效模块，然后你就可以利用 webpack 的打包能力，对它们进行处理。

本质上，webpack loader 将所有类型的文件，转换为应用程序的依赖图（和最终的 bundle）可以直接引用的模块。

在更高层面，在 webpack 的配置中 loader 有两个目标：

1. test 属性，用于标识出应该被对应的 loader 进行转换的某个或某些文件。
2. use 属性，表示进行转换时，应该使用哪个 loader。

const path = require('path');

const config = {
  entry: './path/to/my/entry/file.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'my-first-webpack.bundle.js'
  },
  module: {
    rules: [
      { test: /\.txt$/, use: 'raw-loader' }
    ]
  }
};

module.exports = config;

以上配置中，对一个单独的 module 对象定义了 rules 属性，里面包含两个必须属性：test 和 use。这告诉 webpack 编译器(compiler) 如下信息：

“嘿，webpack 编译器，当你碰到「在 require()/import 语句中被解析为 '.txt' 的路径」时，在你对它打包之前，先使用 raw-loader 转换一下。”

plugins:

loader 被用于转换某些类型的模块，而插件则可以用于执行范围更广的任务。插件的范围包括，从打包优化和压缩，一直到重新定义环境中的变量。

使用一个插件，你只需要 require() 它，然后把它添加到 plugins 数组中。多数插件可以通过选项(option)自定义。你也可以在一个配置文件中因为不同目的而多次使用同一个插件，这时需要通过使用 new 操作符来创建它的一个实例。

(2).常用配置项：

entry：可以存在多个入口起点。

    单个入口语法：（前者是后者的简写） entry: string|Array<string>

const config = {
  entry: './path/to/my/entry/file.js'
};

const config = {
  entry: {
    main: './path/to/my/entry/file.js'
  }
};

当你向 entry 传入一个数组时会发生什么？向 entry 属性传入「文件路径(file path)数组」将创建“多个主入口(multi-main entry)”。在你 想要多个依赖文件一起注入，并且将它们的依赖导向(graph)到一个“chunk”时，传入数组的方式就很有用。

    对象语法： entry: {[entryChunkName: string]: string|Array<string>}

const config = {
  entry: {
    app: './src/app.js',
    vendors: './src/vendors.js'
  }
};

此设置允许你使用 CommonsChunkPlugin 从「应用程序 bundle」中提取 vendor 引用(vendor reference) 到 vendor bundle，并把引用 vendor 的部分替换为 __webpack_require__() 调用。如果应用程序 bundle 中没有 vendor 代码，那么你可以在 webpack 中实现被称为长效缓存的通用模式。

output：只指定一个输出配置。

filename： 用于输出文件的文件名。

path： 目标输出目录的绝对路径。

如果配置创建了多个单独的 "chunk"（例如，使用多个入口起点或使用像 CommonsChunkPlugin 这样的插件），则应该使用占位符(substitutions)来确保每个文件具有唯一的名称。

{
  entry: {
    app: './src/app.js',
    search: './src/search.js'
  },
  output: {
    filename: '[name].js',
    path: __dirname + '/dist'
  }
}

resolve: 配置模块如何解析。

例如，当在 ES2015 中调用 import "lodash"，resolve 选项能够对 webpack 查找 "lodash" 的方式去做修改。

resolve.alias : 创建 import 或 require 的别名，来确保模块引入变得更简单。

alias: {
  Utilities: path.resolve(__dirname, 'src/utilities/')
}
现在，替换「在导入时使用相对路径」这种方式，就像这样：

import Utility from '../../utilities/utility';
你可以这样使用别名：

import Utility from 'Utilities/utility';

resolve.extensions : 自动解析确定的扩展。能够使用户在引入模块时不带扩展。

自动解析确定的扩展。默认值为：

extensions: [".js", ".json"]
能够使用户在引入模块时不带扩展：

import File from '../path/to/file'

module.rules: 创建模块时，匹配请求的规则数组。这些规则能够修改模块的创建方式。这些规则能够对模块(module)应用 loader，或者修改解析器(parser)。

loader的使用方式：

    配置（推荐）：在 webpack.config.js 文件中指定 loader。

  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          { loader: 'style-loader' },
          {
            loader: 'css-loader',
            options: {
              modules: true
            }
          }
        ]
      }
    ]
  }

    内联：在每个 import 语句中显式指定 loader。

import Styles from 'style-loader!css-loader?modules!./styles.css';

    CLI：在 shell 命令中指定它们。

webpack --module-bind jade-loader --module-bind 'css=style-loader!css-loader'

plugins: 插件目的在于解决 loader 无法实现的其他事。

由于插件可以携带参数/选项，你必须在 webpack 配置中，向 plugins 属性传入 new 实例。

用法一：配置文件

const HtmlWebpackPlugin = require('html-webpack-plugin'); //通过 npm 安装
const webpack = require('webpack'); //访问内置的插件
const path = require('path');

const config = {
  entry: './path/to/my/entry/file.js',
  output: {
    filename: 'my-first-webpack.bundle.js',
    path: path.resolve(__dirname, 'dist')
  },
  module: {
    rules: [
      {
        test: /\.(js|jsx)$/,
        use: 'babel-loader'
      }
    ]
  },
  plugins: [
    new webpack.optimize.UglifyJsPlugin(),
    new HtmlWebpackPlugin({template: './src/index.html'})
  ]
};

module.exports = config;

用法二：Node API

  const webpack = require('webpack'); //访问 webpack 运行时(runtime)
  const configuration = require('./webpack.config.js');

  let compiler = webpack(configuration);
  compiler.apply(new webpack.ProgressPlugin());

  compiler.run(function(err, stats) {
    // ...
  });

devtool: 控制是否生成以及如何生成source-map

对于开发环境，通常希望更快速的 source map，需要添加到 bundle 中以增加体积为代价，但是对于生产环境，则希望更精准的 source map，需要从 bundle 中分离并独立存在。

适用于开发环境：

eval - 每个模块都使用 eval() 执行，并且都有 //@ sourceURL。此选项会非常快地构建。主要缺点是，由于会映射到转换后的代码，而不是映射到原始代码（没有从 loader 中获取 source map），所以不能正确的显示行数。

eval-source-map - 每个模块使用 eval() 执行，并且 source map 转换为 DataUrl 后添加到 eval() 中。初始化 source map 时比较慢，但是会在重新构建时提供比较快的速度，并且生成实际的文件。行数能够正确映射，因为会映射到原始代码中。它会生成用于开发环境的最佳品质的 source map。

cheap-eval-source-map - 类似 eval-source-map，每个模块使用 eval() 执行。这是 "cheap(低开销)" 的 source map，因为它没有生成列映射(column mapping)，只是映射行数。它会忽略源自 loader 的 source map，并且仅显示转译后的代码，就像 eval devtool。

cheap-module-eval-source-map - 类似 cheap-eval-source-map，并且，在这种情况下，源自 loader 的 source map 会得到更好的处理结果。然而，loader source map 会被简化为每行一个映射(mapping)。

适用于生产环境：

source-map - 整个 source map 作为一个单独的文件生成。它为 bundle 添加了一个引用注释，以便开发工具知道在哪里可以找到它。

hidden-source-map - 与 source-map 相同，但不会为 bundle 添加引用注释。如果你只想 source map 映射那些源自错误报告的错误堆栈跟踪信息，但不想为浏览器开发工具暴露你的 source map，这个选项会很有用。

nosources-source-map - 创建的 source map 不包含 sourcesContent(源代码内容)。它可以用来映射客户端上的堆栈跟踪，而无须暴露所有的源代码。你可以将 source map 文件部署到 web 服务器。

在使用 uglifyjs-webpack-plugin 时，你必须提供 sourceMap：true 选项来启用 source map 支持。

3.插件的使用及介绍：

(1).通用插件：

(--1).nyan-progress-webpack-plugin：

可以在生产构建时，显示一个彩虹猫（Nyan）形式的进度条，然后在过程中小猫会上下跳，构建完成时，可以自定义小猫说的话。

// webpack.config.prod.js
const NyanProgressPlugin = require('nyan-progress-webpack-plugin')  
...
plugins: [  
  new NyanProgressPlugin()  
]
...

(--2).webpack.DefinePlugin：

允许创建一个在编译时可以配置的全局常量。这可能会对开发模式和发布模式的构建允许不同的行为非常有用。如果在开发构建中，而不在发布构建中执行日志记录，则可以使用全局常量来决定是否记录日志。

new webpack.DefinePlugin({
  PRODUCTION: JSON.stringify(true),
  VERSION: JSON.stringify("5fa3b9"),
  BROWSER_SUPPORTS_HTML5: true,
  TWO: "1+1",
  "typeof window": JSON.stringify("object")
})

(2).开发环境使用的插件：

(--1).html-webpack-plugin:

简化了HTML文件的创建，以便为你的webpack包提供服务。这对于在文件名中包含每次会随着编译而发生变化哈希的 webpack bundle 尤其有用。

如果你有多个 webpack 入口点，他们都会在生成的HTML文件中的 script 标签内。

如果你有任何CSS assets 在webpack的输出中（例如，利用ExtractTextPlugin提取CSS），那么这些将被包含在HTML head中的<link>标签内。

new HtmlWebpackPlugin({
        filename: 'index.html',  //要写入HTML的文件。默认为index.html。
        inject: 'body',  //当传递true或'body'时，所有的javascript资源将被放置在body元素的底部。 'head'将脚本放在head元素中
        template: path.join(src, 'index.html'),  //模板路径
        chunksSortMode: 'none' //允许控制chunk在被包含到HTML之前应该如何排序。
    })

(--2).extract-text-webpack-plugin:

将所有的入口 chunk(entry chunks)中引用的 *.css，移动到独立分离的 CSS 文件。因此，你的样式将不再内嵌到 JS bundle 中，而是会放到一个单独的 CSS 文件（即 styles.css）当中。 如果你的样式文件大小较大，这会做更快提前加载，因为 CSS bundle 会跟 JS bundle 并行加载。

new ExtractTextPlugin({
        filename: '[name].css'  //生成文件的文件名。可能包含 [name],[id] and [contenthash]
    })

require('extract-text-webpack-plugin').extract()：从一个已存在的 loader 中，创建一个提取(extract) loader。

loader: ExtractTextPlugin.extract({
        fallback: 'style-loader',  //loader（例如 'style-loader'）应用于当 CSS 没有被提取(也就是一个额外的 chunk，当 allChunks: false)
        use: 'css-loader' //loader 被用于将资源转换成一个 CSS 导出模块 (必填)
    })

(--3).browser-sync-webpack-plugin:

new BrowserSyncPlugin({
        host: '127.0.0.1',
        port: 9090,
        proxy: 'http://127.0.0.1:9000/',
        logConnections: false,
        notify: false
    }, {
        reload: false
    })

(--4).webpack.HotModuleReplacementPlugin: 模块热替换

new webpack.HotModuleReplacementPlugin()

(--5).webpack.NoEmitOnErrorsPlugin:

在编译出现错误时，使用 NoEmitOnErrorsPlugin 来跳过输出阶段。这样可以确保输出资源不会包含错误。

new webpack.NoEmitOnErrorsPlugin()

(--6).connect-history-api-fallback:

一个能够代理请求返回一个指定的页面的中间件，对于单页应用中使用HTML5 History API非常有用。

【原因：访问http://cnode.lsqy.tech，进入首页，点击下面的tab栏，一切都是很正常的，但当这时候你 ctrl+command+R 或 点击浏览器的刷新按钮 或 在地址栏上再敲一下回车，总之就是刷新，发现就会出现404了，比如这样的错误Cannot GET /message/,因为默认浏览器会认为你是在请求服务端的路由，服务端那边没有对应的处理，所以自然就会出错了。】

app.use(require('connect-history-api-fallback')());

(--7).webpack-dev-middleware:

 是一个容器(wrapper)，它可以把 webpack 处理后的文件传递给一个服务器(server)。 

app.use(require('webpack-dev-middleware')(compiler, {
    noInfo: true,
    publicPath: config.output.publicPath
}));

(--8).webpack-hot-middleware:

在内存中进行代码的编译和资源的提供，但并不写入磁盘来提高性能。

app.use(require('webpack-hot-middleware')(compiler));

(3).生产环境使用的插件：

(--1).html-webpack-plugin:  ...

(--2).copy-webpack-plugin:

将单个文件或整个目录复制到构建目录。

new CopyWebpackPlugin([ // 复制高度静态资源
        {
            context: commonPath.staticDir,  //A path that determines how to interpret the from path
            from: '**/*',
            ignore: ['*.md']
        }
    ])

(--3).exact-text-webpack-plugin: ...

(--4).webapck.optimize.UglifyJsPlugin:

new webpack.optimize.UglifyJsPlugin({
        compress: {
            warnings: false  //是否显示uglifyjs 的警告信息
        }
    })

(--5).webpack.optimize.CommonsChunkPlugin:

用于建立一个独立文件(又称作 chunk)的功能，这个文件包括多个入口 chunk 的公共模块。通过将公共模块拆出来，最终合成的文件能够在最开始的时候加载一次，便存到缓存中供后续使用。这个带来速度上的提升，因为浏览器会迅速将公共的代码从缓存中取出来，而不是每次访问一个新页面时，再去加载一个更大的文件。

new webpack.optimize.CommonsChunkPlugin({
        // 公共代码分离打包
        names: ['vendor', 'mainifest']
    })