但是每次这么打包有点繁琐，所以在package.json对命令进行简写
//在package.json文件里，将命令简写成自定义命令
“scripts”: {
“test”: “echo “Error: no test specified” && exit 1”,
“bulid”: “webpack --env production --config webpack.common.js”,
“dev”:“webpack-dev-server --env development --config webpack.common.js”
},
在执行npm run build的时候，自动执行了打包生产环境的代码，在执行npm run dev的时候，自动执行打包开发环境，这样就简单多了；
基础文件中环境配置+小结
那么，新问题又出现了，如果在基础配置文件里的通用loader，也需要根据环境的不同，配置不同的插件，比如poster-loader，这个loader是一个平台loader，需要根据不同的环境区分不同的配置怎么办？
其实一样的，而且务必记住，webpack.config.js这个文件本质上就是一个js文件，只不过这个js文件的属性名，值是需要按照webpack规定的格式书写，既然是js文件，那么完全不必要考虑太多，写js语法就可以了；
比如这个postcss-loader
use:[
{
loader:‘postcss-loader’,
options:{
ident:‘postcss’,
//使用三元运算符
plugins:env===‘production’?[
//自动补全前缀插件
require(‘autoprefixer’)({
‘overrideBrowserslist’:[
“>1%”,“last 2 versions”
]
}),
//自动使用下一代语法插件
require(‘postcss-cssnext’)(),
//自动合并成精灵图插件
require(‘postcss-sprites’)({
spritePath:‘dist/sprite’,
retina:true
})
]:
[
//自动补全前缀插件
require(‘autoprefixer’)({
‘overrideBrowserslist’:[
“>1%”,“last 2 versions”
]
}),
//自动使用下一代语法插件
require(‘postcss-cssnext’)()
]
}
},
]
plugins中值既然是一个数组，数组中的每一项都是需要引入的插件，那么是不是可以通过三元运算符直接去判断参数是不是生产环境，甚至，可以把这个值单独提取到外面，在一开始的时候就判断是不是生产环境，比如
module.exports = env => {
//直接判断是不是生产环境
let production = env === “production”?[]:[]
var common = {
enrty:{
app:‘./app.js’
},
output:{
filename:‘bundle.js’
},
module:{
rules:[]
},
plugins:[]
}
return common;
}
在开头判断好了之后，使用的时候直接赋值就好了
use:[
{
loader:‘postcss-loader’,
options:{
ident:‘postcss’,
//使用三元运算符
plugins:production
}
},
]
包括开发环境文件和生产环境文件，其实如果愿意在一个文件里处理，那不分也没有问题，也不需要引入merge，直接判断参数，然后再决定需不需要将值加上就可以了；
开发环境文件
开发环境文件示例
const webpack = require(‘webpack’);
module.exports = {
devtool:‘cheap-module-source-map’,
devServer:{
port:9001,
overlay:true,
hot:true,
hotOnly:true
},
plugins:[
new webpack.HotModuleReplacementPlugin(),
new webpack.NamedModulesPlugin()
]
}
生产环境文件
生产环境示例
const webpack = require(‘webpack’);
var htmlWeboackPlugin = require(‘html-webpack-plugin’);
module.exports = {
optimization:{
minimize:false
},
plugins:[
new htmlWeboackPlugin({
filename:‘index.html’,
template:‘./index.html’,
minify:{
collapseWhitespace:true
},
inject:true
})
]
}
在webpack4中，对环境的区分更简单了，官方对其集成了loader，比如
//打包命令
webpack --mode production/development/none
只需要运行命令–mode，并且跟上指定模式，webpack会自动以一些固定的模版运行打包，比如指定–mode production（生产模式），即使我们在配置文件中没有编写：压缩，tree-shaking等插件，但是webpack依旧会帮忙去使用这个功能；
**
另外，在webpack4中是需要加上mode属性的，否则在执行打包的会出现警告提示，当然要是无视也没上面关系，加上mode之后，就不需要指定上面的关键词了，官方也是比较推荐写入mode，比如
module.exports = env => {
var common = {
mode:‘development’,//或者production，生产模式
enrty:{
app:‘./app.js’
},
output:{
filename:‘bundle.js’
},
module:{
rules:[]
},
plugins:[]
}
return common;
}
当指定了mode为development之后，执行打包的时候，直接输入webpack，此时打包的方式等同于输入了
webpack --mode development
==========================================================================
先说个简单的例子，跨域，尤其是使用Vue的时候，当我们把模版样式写好，需要对接接口的时候，如果直接启动vue项目，那么就会报跨域错误，因为本地调试的域名是loaclhost，与服务器的接口的域名不一致，此时就没有办法正常连调项目；在webpack中就内置了解决这些问题的方法；
也有全局和局部之分，但是通常我们都是在package.json中配置webpack-dev-server，因此通常使用的是局部安装
//在 项目的根路径下
cnpm install webpack-dev-server --save
在webpack.config.js等配置文件中，与entry，output这些同级属性中加入devServer属性，比如
module.exports = env => {
//直接判断是不是生产环境
let production = env === “production”?[]:[]
var common = {
enrty:{
app:‘./app.js’
},
output:{
filename:‘bundle.js’
},
module:{
rules:[]
},
plugins:[],
//在webpack.config.js或其他指定配置文件中配置webpack-dev-server
//webpack-dev-server配置
//固定对象的key为：devServer，值是一个对象
devServer:{
//端口
port:9001,
//默认是true，一般不用管，是开启浏览器上当前页面的状态
inline:true,
//开启遮罩，具体效果就是vue那种错误遮罩
overlay:true,
//路径重定向，假如页面的路径是错误的，如果未开启，会提示路径错误，找不到页面
//重定义了之后，如果路径错误，那么会仅会停留在当前页面，不会跳转
// histroyApiFallback:true,
///路径重定向进一步使用
historyApiFallback:{
//定义路径，值是一个数组，数组的每一个值代表了一个路径规则
rewrites:[
{
//使用正则匹配
from:/^/([-~])/,
//重定向路径
to:function(context){
return ‘./’+context.macth[1]+‘.html’
}
}
]
},
//代理接口
proxy:{
// '/'代表，碰到以 / 开头的地址就进行代理转发
‘/’:{
//转发的目标地址
//这里也就写上了接口的服务器地址，解决跨域不是同源的问题
target:‘’,
changeOrigin:true,
//重写地址，简化路径名
pathRewirte:{
//key：如果路径中有以/comments的路径地址
//value：改写为/api/comments
//这样就可以大大的减少路径名了
‘^/comments’:‘/api/comments’
},
//代理的请求头
headers:{
}
},
//多个就写多个规则对象
‘/smart’:{
}
},
//热更新
hot:true, //开启热更新
hotOnly:true, //仅仅使用热更新，不使用其他
}
}
return common;
}
值的注意的是，热更新hot和extact-text-webpack-plugin这个插件是不相互兼容的，因此需要把extact-text-webpack-plugin这个插件的注册状态中的disable，设置为true，表示禁用插件；
========================================================================
简单的说，source-map为了方便调试，我们需要知道打包后的代码对应于原文件的位置，因为打包后代码都是被压缩过了，如果线上报错了，根本查不到报错的位置，因为所有关联的js最终都会被合并成一个js文件；
source-map不需要安装，直接开启就好了，它也是和entry，output这些同级，值是规定好的，不同的值代表不同的含义
//开启source-map
devtool:‘eval-source-map’,
//webpack-dev-server配置
devServer:{
},
//它是一个数组
plugins:[
]
开发模式
开发模式下最常用的就这几个
-
eval：构建最快，只能定位到打包后的代码。适用度：无需source-map。
-
eval-source-map：构建较快，生产一个dataUrl形式的sourcemap。适用度：需要简单的调试。
-
cheap-eval-source-map：构建快，重新构建慢，定位到转换后的代码。适用度：较为详细的调试。
-
cheap-module-source-map：构建慢，重构快，能定位到原代码。适用度：开发过程中一般用这个。
生产模式
-
source-map：构建和重构都很慢，能定位原始代码。适用度：上线后一般用这个。
-
hidden-source-map：候检和重构都很慢，能定位原始代码，但不追加注释。适用度：一般不使用。
-
nosource-source-map：构建和重构都很慢，不能定位到源码。适用度：一般不使用。
==============================================================
概述
代码分割的目的为了减少加载代码大小和提取公共资源，减少加载次数做的优化；比如，多页面项目中，a页面和b页面都引入了jq，那么正常情况下，jq会被打包2次，这显然是不合理，jq只需要单独提取出来后打包一次就够了，没有必要混入在a，b中被打包两次；
使用到的webpack的核心功能：optimization，关于这个功能，具体可以查看官网核心功能optimization介绍，或者核心功能optimization介绍；
注意，版本差异：webpack3中使用：commonChunksPlugin，而在webpack4中使用optimization下的SplitChunks，下例以webpack4为主
多页面打包
多页面优化的核心概念，就是提取公共依赖，把几个页面中都用到的依赖给打包为一个单独文件，这样a页面在浏览器被加载完之后，打开了b页面，因为b页面也使用到了这个相同的依赖，因此b页面的打开速度会非常快；
因此，多页面应用一般会这么打包：主页面代码+公共依赖+第三方包+webpack运行代码；
//这个插件是一个辅助性的，作用是删除上一次打包的代码，有时候会遇到上次打包的代码没有被删除
const {CleanWebpackPlugin} =require(‘clean-webpack-plugin’)
module.exports = {
mode:‘development’,
entry:{
a:‘./a.js’,
b:‘./b.js’
},
output:{
filename:‘./[name].[hash:4].min.js’
},
module:{
rules:[]
},
optimization:{
//使用webpack4中的splitChunks
splitChunks:{
name:true,
//优化的类型，all代表所有的都进行优化打包
chunks:‘all’,
//设定公共依赖提取最低大小，小于这个值的公共依赖将不会被提取出来，10000=10kb
minSize:10000,
//缓存组，用于设定指定打包
cacheGroups:{
//打包命名为m2
m2:{
//值是一个正则，代表匹配到这个正则名字文件必须单独打包，这里是m2的文件单独打包
test:/m2/
}
}
},
//运行代码单独打包
runtimeChunk:true
},
plugins:[
new CleanWebpackPlugin(),
]
}
单页面打包
与多页面打包不同，单页面不会存在公共依赖的问题，因为只有一个入口，那么单页面打包优化主要就是减少文件体积，因此，需要拆分应用，把需要异步加载的内容改成异步加载；
因此，单页面应用一般会这么打包：主业务代码+异步模块+第三方包+webpack运行代码；
//这个插件是一个辅助性的，作用是删除上一次打包的代码，有时候会遇到上次打包的代码没有被删除
const {CleanWebpackPlugin} =require(‘clean-webpack-plugin’)
module.exports = {
mode:‘development’,
entry:{
a:‘./a.js’,
b:‘./b.js’
},
output:{
filename:‘./[name].[hash:4].min.js’
},
module:{
rules:[]
},
optimization:{
splitChunks:{
name:true,
chunks:‘all’,
//设定公共依赖提取最低大小
minSize:10000,
},
//运行代码单独打包
runtimeChunk:true
},
plugins:[
new CleanWebpackPlugin(),
]
}
这样其实就可以了，和多页面打包反而少了配置，因为webpack在遇到异步加载的部分本来就会单独打一个包，因此不需要单独配置；
体积控制，其实也差不多，就是压缩，提供公共代码，压缩在webpack3和webpack4中使用的方法不一样，在webpack3中，使用的是：optimize.UglifyJsplugin()，在webpack4中，使用的是：optimization.minimize
webpack4示例大致配置如下：
optimization:{
//体积压缩，将minimize属性设置成true
minimize:true,
splitChunks:{
name:true,
chunks:‘all’,
//设定公共依赖提取最低大小
minSize:10000,
//设定强制打包
cacheGroups:{
//打包命名为m2
m2:{
//提取规则，找到名字是m2的文件单独打包
test:/m2/
}
}
},
//运行代码单独打包
runtimeChunk:true
}
结尾
学习html5、css、javascript这些基础知识，学习的渠道很多，就不多说了，例如，一些其他的优秀博客。但是本人觉得看书也很必要，可以节省很多时间，常见的javascript的书，例如：javascript的高级程序设计，是每位前端工程师必不可少的一本书，边看边用，了解js的一些基本知识，基本上很全面了，如果有时间可以读一些，js性能相关的书籍，以及设计者模式，在实践中都会用的到。
开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】
高级程序设计，是每位前端工程师必不可少的一本书，边看边用，了解js的一些基本知识，基本上很全面了，如果有时间可以读一些，js性能相关的书籍，以及设计者模式，在实践中都会用的到。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
