前言
升级webpack4，一定要去看文档，特别是更新说明，不要自持用过原本webpack就自己开始折腾。折腾到后面，可能就默默流下眼泪了。
webpack4的变化
webpack-cli抽离
webpack-cli被单独拆了出来，使用的时候如果只是全局装了CLI，直接执行的时候是可以的。
webpack --config ./config/webpack.dev.js
如果是写在npm hook里面会发现有点问题：
//package.json"scripts": { "dev": "webpack --config ./config/webpack.dev.js"
}//shallnpm run dev此时就会给提示：
One CLI for webpack must be installed. These are recommended choices, delivered as separate packages: - webpack-cli (https://github.com/webpack/webpack-cli) The original webpack full-featured CLI. - webpack-command (https://github.com/webpack-contrib/webpack-command) A lightweight, opinionated webpack CLI. We will use "npm" to install the CLI via "npm install -D". Which one do you like to install (webpack-cli/webpack-command):
如果是我没有全局装，我肯定会意识到要选一个，这个坑关键是我全局装了。所以就在那折腾半天。
其实官方文档开头就说明了。
npm install webpack webpack-cli --save-dev
安装完成之后，继续执行发现有warning：
WARNING in configuration The 'mode' option has not been set, webpack will fallback to 'production' for this value. Set 'mode' option to 'development' or 'production' to enable defaults for each environment. You can also set it to 'none' to disable any default behavior. Learn more: https://webpack.js.org/concepts/mode/
mode规则
配置规则：必须在production 和 development之间选择一种,以便webpack 使用相应模式的内置优化
production支持所有类型的优化已生成最优bundles
development允许注释、提示和eval devtooldevtool的差别可以参考这里
production不支持watching、development针对快速增量重建进行了优化
production支持 module concatenating（Scope Hoisting）即作用域提升，可以将模块打包在一个函数里，这样减少了函数声明，文件体积也会减小。详细参考看这里
process.env.NODE_ENV被设置用来区分环境（仅仅在构建代码而非config里面)
有一个hidden none mode的模式可以禁用所有内容
用法：
配置文件中：
module.exports = {entry: Entrys,mode: 'development'}cli 参数传入
webpack --mode=development
两种方式都是可行的，不过我遇到过一个很坑的问题，困扰自己好几天，最后知道真相的自己眼泪掉下来后面再提这个问题。
零配置快速开始
因为一直被吐槽配置太累，加上parcel给的压力，webpack4也支持零配置打包了。
如果没有配置文件，会默认以./src/index.js作为entry开始打包。
如果配置了webpack.config.js或者指定了--config 的文件路径，则依据对应配置文件开始。
问题表现
在webpack.config.js中配置了entry、mode等相关属性，配置文件如下：
module.export = { mode:'production', entry:{ app:'./src/test.js', index:'./src/test.js'
}, output: { path: process.cwd() + '/dist', filename: '[name].[hash].js', chunkFilename: '[name].[chunkhash].js', crossOriginLoading: 'anonymous'
}, cache: true, devtool: 'cheap-source-map', externals: { jquery: 'jQuery'
}, module: { rules: [
{ test: /\.(js|jsx)?$/, include: [
path.resolve(__dirname, "../src")
], exclude: [ 'node_modules',
path.resolve(__dirname, "../node_modules")
], use: [
{ loader: 'babel-loader', options:{ presets:['es2015']
}
}
]
}
]
}, resolve: { modules: [ 'node_modules'
], extensions: [".js", ".json", ".jsx", ".css"],
}, devServer: { proxy: { // proxy URLs to backend development server
'/api': 'http://localhost:3000'
}, contentBase: path.resolve(__dirname, "../dist"), hot: true, open:true
}, plugins: [ new CleanWebpackPlugin(['dist']), new HtmlWebpackPlugin({ title:'test'
}), new webpack.HotModuleReplacementPlugin()
]
}package.json命令配置:
"scripts": { "build": "webpack --config webpack.prod.js"
}//执行打包npm run build发现始终会有上面选择mode类型的提示，这让人不能接受，另外提示没有./src/index.js文件，但是我的配置入口是别的文件，这样让人很莫名
ERROR in Entry module not found: Error: Can't resolve './src' in '/Users/****'
本着跟着提示解决问题的原则，少文件那就建一个呗(后来发现这种思维有时候有用，有时候还真要慎重)，问题表现虽然一致，实质可能有所不同。
新建之后是可以运行了但是我们的配置文件好像没起作用，
dist下的打包文件是默认的main.js
而非我们指定的app和index
为了确保进入配置文件，我打了几个log，竟然都有输出，说明进去了，这问题就诡异了。
console.log(path.resolve(__dirname, './src')) //输出正确路径module.export = { //*****//
}版本统一
初步猜想是版本问题，确实也有issue上提到过某些版本存在问题，对照着官方demo锁定版本之后问题依然存在。
猜测：应该是配置文件存在错误
配置检查
将官方最基本的配置拉进来拷贝进来试了一下，依然存在问题没能解决。
猜测：本地的环境存在问题，npm，node等版本
查看之后发现版本都是满足的。
运行demo
将demo拉到本地并启动，demo正常打包，说明本地环境是ok的。那么问题就明显了，我的配置文件或者项目搭建有问题，对照着demo的配置项，配置项没有明显问题，这样的话将，配置信息放入到demo中去，修改之后发现起作用，我又重新审视了下我的配置文件，不仅仅局限于配置部分的时候，发现
//我的写法，这样webpack拿到的就是undefined了。module.export//别人的demomodule.exports
webpack的兼容处理
webpack会将 webpack --config 传入的文件与本身默认配置进行merge，保证本身打包不出错。为了证明我们的推论，将配置文件只剩下output属性，并加上src/index.js
module.exports = { output: { path: process.cwd() + '/dist1', // 直接的入口模zzz块名
filename: '[name].js', // 非入口模块，也就是不需要打包到一起的，但又可能会用到，
// 这不就是按需加载的么
chunkFilename: '[name].[chunkhash].js', crossOriginLoading: 'anonymous'
}
}执行之后会发现打包到/dist1下面。所以上面写错module.exports的时候，走的完全是默认配置。前面的log打在了module.exports之前执行是正确的。
结尾
当遇到不可思议的问题的时候，建议静下心看一看，不要盲目搜索，另外最可靠的参考就是官方文档和实例，注意对比版本和环境，如果都没问题，那么再去尝试网上的各种解决方法。
这里总结一下给自己一个记录，希望解决思路能帮助其他人。