webpack

  why do it?

   webpack是一款自动打包工具，主要是针对js文件进行打包，根据入口文件开始建立一个依赖关系图，将依赖图中的js文件（模块）打包为一个或多个包。

        随着前端代码实现的功能越来越复杂，代码的后期维护变得越来越难，于是进行了前端模块化开发。这样前端代码的维护变得简单，但是也出现了新的问题比
如：由于js文件的数量增加，网页向服务器请求的次数增加，导致页面加载速度变慢；无法直接在js代码中看出js文件之间相互存储位置的关系，必须通过dist。html
文件才能查看；js文件必须按照规定顺序加载才能正常实现功能。

 how do it?

全手动命令行打包：node_modules/.bin/webpack app/main.js public/bundle.js，这条命令的是使用webpack把打包后的文件命名为bundle.js放在public文件夹下，其中app/main,js是项目的入口。
通过配置文件一行命令打包：又要配置输出文件名之类的东西，在命令行输入比较麻烦，我们可以使用文件配置的方式，在项目的根目录中新建一个webpack.congfig.js的文件，把下面这些内容写入进去。

webpack.congfig.js

context(入口上下文):是入口文件所处的目录的绝对路径。默认情况下，是当前项目根目录，entry的app属性会拼接上上下文内容去寻找入口文件（绝对路径）

入口（entry）： app 是入口名称，如果 output.filename 中有 [name] 的话，就会被替换成 app。

出口（output）：
  publicPath：在开发环境下，通常是使用webpack-dev-server，因为它的热加载，实时更新。而在生产环境下，则是使用wepback命令进行打包，生成一个js 文件。上面publicPath的说法适用于生产环境。当使用webpack命令进行打包上生产时，它确实是在静态资源路径前面
加上publicPath的值。 但在开发环境下，使用webpack-dev-server 进行开发时，它却不是在静态文件的路径上加publicPath的值，相反，它指的是webpack-dev-server 在进行打包时生成的静态文件所在的位置。也就是说publicPath在不同的环境下，有不同的意思。
静态资源的公共路径，可以记住这个公式： 静态资源最终访问路径=output.publicPath+资源loader或插件等配置路径。举个例子， publicPath 配置为 /dist/，图片的 url-loader 配置项为 name:'img/[name].[ext]' ，那么最终打包出来文件中图片的引用路径为 
output.publicPath+'img/[name].[ext]'='/dist/img/[name].[ext]'。

 

modlu：

module: {
  rules: [
    {
      test: /\.js$/, //以 .js 结尾的文件。
      use: ["babel-loader"], //使用babel-loader 对以.js结尾的文件进行解析。
      include: path.resolve(__dirname, 'src') //通过include 规定只匹配src目录下的js文件。
    },
    {
      test: /\.css$/, //匹配以 .css结尾的文件
      use: ['style-loader', 'css-loader'], //可以看到 use 后跟的是一个数组，所很明显我们可以使用一组 loader 来对某一种文件进行解析，但是这里需要注意的是，解析顺序是从右到左，也就是：css文件 -> css-loader->style-loader，完成解析。
      exclude: path.resolve(__dirname, 'node_modules'), //通过exclude排除 node_modules 目录下的所有文件。
    },
    {
      test: /\.(gif|png|jpe?g|eot|woff|ttf|svg|pdf)$/, // 匹配非文本文件
      use: ['file-loader'], //使用 file-loader 来进行解析。
    },
  ]
}

在 use 中我们除了使用一个字符串来设置 loader 此外还可以通过一个对象来表示对 loader 的配置

//方式1
module: {
  rules: [
    {
      test: /\.css$/, //匹配以 .css结尾的文件
      use: ['style-loader', 'css-loader?modules'],
    },
  ]
}

// 方式2
module: {
  rules: [
    {
      test: /\.css$/, //匹配以 .css结尾的文件
      use: [
            {loader:'style-loader'}, 
            {loader:'css-loader?modules',opions:{modules:true}}
      ],
    },
  ]
}

 

插件（plugins）：

模式：

resolve：webpack中使用resolve字段来配置模块的相关解析策略。本质上是通过对resolve库的使用来解析模块路径，帮助 webpack 找到 bundle 中以require/import引入的模块代码。模块可以是一个文件也可以是一个文件夹，可以是相对路径（以./或../开头），
也可以是绝对路径（以/或c:盘符开头），还可以是模块路径（除却以上两种情况如：import "module/lib/file";）。无论是哪一种情况的引入，最终解析得到的都是一个绝对路径的文件，这个文件可能有扩展名，也可能没有扩展名，有扩展名直接打包，如果没有扩展名，
resolve也为我们提供了预留选项

 

 extensions扩展名选项在resolve追踪到的文件如果没有扩展名时，会尝试在其提供的扩展名选项里进行匹配。

resolve.modules：它会告诉 webpack 解析模块时应该搜索的目录。默认配置：modules: ["node_modules"]，即我们通常以模块路径引入的模块，是在node_module目录下进行查找的。

resolve: {
    // 配置解析模块路径别名: 优点简写路径 缺点路径没有提示
    alias: {
      $css: resolve(__dirname, 'src/css')
    },
    // 配置省略文件路径的后缀名
    extensions: ['.js', '.json', '.jsx', '.css'],
    // 告诉 webpack 解析模块是去找哪个目录
    modules: [resolve(__dirname, '../../node_modules'), 'node_modules']
  }

 

resolve.descriptionFiles ：这个选项会定义一个用于描述的 JSON 文件，默认为descriptionFiles：['package.json']。这个json里会包括某些描述路径的字段如main、module等，这些字段的值会指定一个具体模块指向的路径。当我们导入的模块是一个目录（通常是一个npm包）如import from 'lodash'，此时根据resolve.modules会到node_module目录下去找lodash，发现是一个文件夹，然后去看是否包含我们配置的描述文件，package.json。如果包含，则会去查找package.json里的相应字段，这时我们就需要另外一个选项resolve.mainFields 。

resolve.mainFields：选项将决定在package.json中使用哪个字段导入模块。mainFields: ["module", "main"]。依次查找resolve.mainFields即module或main，如存在module字段即不再向后查找main字段了，如果module字段不存在，再去查看main字段是否存在

 

 resolve.mainFiles ，默认配置mainFiles: ["index"]，此选项就是在package.json文件不存在或者package.json文件中的 main 字段没有返回一个有效路径，则按照顺序查找resolve.mainFiles配置选项中指定的文件名，看是否能在 import/require 目录下匹配到一个存在的文件名。

resolve.alias 配置项通过别名来把原导入路径映射成一个新的导入路径。例如使用以下配置：

resolve: {
    alias: {
      $css: resolve(__dirname, 'src/css')
    }
 }

这样在js文件里面引用的时候可以简写文件路径

import '$css/index.css'