source map和一些感触

对于source map应该很多人知道，简单来说就是源码映射，就我知道的，也就我一个老乡项目中用到过，反正我在项目中从来没机会去研究使用。

为什么需要source map，很简单，一般我们使用的各种插件都是压缩、多个文件合并、编译转化的，所以对于出错之后的调试很不好处理，Source map就是因此而生，可以让我们准确找到错误的源码位置。

Webpack中配置source map是devtool字段，有很多不同配置，比如常用的source-map、eval-source-map、cheap-module-source-map等。去官网看，那么多配置其实就是几个关键字的各种组合：

source-map、cheap、eval、module、hidden、nosource、inline。

这几个关键字，我只是大概试了试，有点混乱，就不截图了，大概简单说一下：

source-map：产生.map文件

eval：产生的代码用eval包裹，会在末尾追加注释 //@ sourceURL，通过sourceUrl定位原始代码，不产生.map文件，而且是转换后的代码

cheap：产生的文件不含有列信息，只有行信息

然后另外的几个我就没弄懂什么意思了，按照字面意思应该是：

inline行内，不产生.map文件，

nosource没有资源，没有源代码，应该是转化的，

hidden隐藏，打包出来不知道有什么不同，只是不会在末尾追加注释 //@ sourceURL，

module模块，有人说是把loader的sourcemap也添加进去，比如.vue文件出错，会通过loader映射到具体位置。

我是觉得，常用的source-map、cheap、eval知道一下就好，如果真的线上环境需要的话，建议就是配置cheap-module-source-map，定位到行，然后体积也会小一些，够用，开发的话配置cheap-module-eval-source-map，全一些，列当然也是没什么用。而且也可以对照官网给出的一些参数作为参考：

可以看看生产环境开发环境是否合适，也有效率fast和slow对比和是否是转化过的代码还是源码。

还想说一个题外话，今天有个应该是总监级别的跟我说，技术还是专精一个就好，小公司会希望是全栈，但是大一些的一般都会往一个方向去发展，node虽然可以写后台，但是不足以支撑一个大项目，作为中间件使用就够了。刚好，今天另外一个应该是技术负责人跟我说，不会原生Android和ios，对Java和sql也不会，只会一个前端的技术，技能太单一了。

于是有了一些说不出的感受，我只是自己明确的方向是一个前端，从来没有想过会有人觉得全栈并没有那么好。还有一个感受就是，技术水平和层面并不能从出身去衡量，那么大的公司，能说出只会前端，技能太单一的话语，会让我对这个公司的印象打一个折扣。

我还是更赞同往专一的方向去发展，也不排斥成为全栈，毕竟因人而异，每个人都有自己的方向。我不是那种很有天赋和非常努力的人，前端的水那么深，所以从来没有想象过自己去成为一个全栈，往前端架构师方向前进就是了。

虽然说devtool这个配置的source map几乎不用你做些什么，了解一下还是好的，毕竟我是想成为架构师的。

（完）