@H_512_2@

sourceMap的偶遇

接触到sourceMap，其实是在调研ES6时发现的。

在调研ES6引入生产环境的可能性，初步觉得引入项目时需要解决的几个问题：

1. 上线时的打包构建问题

2. 开发环境编译问题，目前chrome都不兼容es6

3. 解决了开发环境编译后，调试问题——开发的代码和浏览器跑的代码不一样

4. 其他没有考虑到的问题等等

其中sourceMap就是在调研第三个问题时，发现的。
想想如果在debug时浏览器显示的是编译后的代码，这个对于调试其实是致命的打击。

而通过目前的调研，发现SourceMap就是这个问题的解决方案。

sourceMap是什么

请大家直接看阮一峰的文章
JavaScript Source Map 详解

原理我简单的理解就是通过map文件产出一个映射关系，将编译后的代码映射到编译前的，然后debug时，浏览器解析的是编译后的，但是呈现给我们的是映射前的开发代码。

sourceMap曾经被忽视

在网上找的一些介绍Source Map的文章，发现Source Map主要是解决一些代码压缩混淆后不好调试的问题。

举个例子，jquery-min调试时非常不方便，但是加上Source Map，可以直接在浏览器中调试jquery压缩前的。

但是真正在开发环境，可能将jquery-min换成jquery，大家觉得会更加方便，无需那么麻烦处理，所以这也是可能没有流行起来的原因。

sourceMap为什么又会被重视

直接拿我遇到的问题说明，ES6语法浏览器执行不了怎么办?

使用babel，ok，babel可以编译成js给浏览器执行。这个时候，编译后的代码必然会和我们开发时的不一样。

这时如果我们希望还和以前使用js一样去调试，怎么办？

只能利用Source Map这种，产生一种映射关系，去将开发中的代码映射到debug工具中。

除了es6，另外一个被看好的tyPEscript（angulejs2使用typescript实现），它也同样存在这个问题（目前没有调研它的调试方式）。

可以预见，这种加入一种编译方式去写js可能是未来的一种趋势。
小小跑题一下，为什么个人觉得是一种趋势，编译做的越牛逼，开发的代码就会越简单，能让开发人员抓住与业务，兼容，适配，自适应的坑都交接编译去解决，大大的提高了工程效率。

sourceMap使用参考

大家看看下面这个链接（需要翻墙）：

http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/

里面还有例子是将java编译成js，然后在chrome中使用sourceMap直接debug java的代码。

我对sourceMap的了解

由于最近比较忙，这篇文章只是初步探索，了解的非常非常浅，没有什么干货，后面有一定成果后还会继续更新sourceMap其他方面。

微信公众号

博客地址

http://tangguangyao.github.io/