为什么内联源地图?

今天,我了解到,可以将源地图直接包含在缩小的JavaScript文件中,而不是将其放在单独的example.min.map文件中。 我想知道: 为什么有人想要这样做

具有源映射好处对我来说是很清楚的 :例如,可以在运行缩小的文件时用原始的,非压缩的源文件debugging错误。 最小化好处也很明显 :源文件的大小大大减小,浏览器下载速度更快。

那么为什么在地球上,我想将源地图包含在缩小的文件中,因为地图的尺寸​​甚至比缩小的代码本身更大

5 Solutions collect form web for “为什么内联源地图?”

我search了四周,唯一的原因是我可以看到人们内联源地图是用于开发。 内联源地图不应用于生产。

将您的缩小文件内联到源映射的理由是,浏览器正在开发和生产中parsing完全相同的JavaScript。 像Closure Compiler这样的一些限定符不仅仅是“简化”代码。 使用高级选项,它也可以做这样的事情:死代码删除,函数内联或激进的variables重命名。 这使缩小的代码(可能)在function上与源文件不同。

这当然也可以通过引用外部源映射文件来完成,但有些人似乎更喜欢内置其构build过程。

如果您在Android设备上远程debuggingChrome,则Chromedebugging器不能只访问设备上的任何文件,而是包含单独的映射文件。 如果将它们包含在内,则不存在此问题。

BrowserifyWebpack这样的JS捆绑工具将捆绑所有.js文件input一个或多个捆绑包,即使在开发模式。 因此,在这种情况下,将内联源地图添加到生成的捆绑包是帮助debugging而不引入额外文件的最简单方法。

在某些情况下,您可能需要将内联源代码映射到评估代码中。 例如,你有一个咖啡脚本的input字段,你想启用在coffeescript代码debbuging。 有一个关于评估代码中的源地图的stackoverflow问题:

使用评估代码获取源地图

您可以在您的注释中包含@sourceURL来指定您的评估代码的URL并加载地图文件(请参阅SourceMap Spec 3的第8页)。 但是,将文件写入某个位置并不总是可行的。

cheap-module-source-map是一个生产build设好得多。

inline-source-map用于在testing时快速和肮脏的构build