为什么要内联源映射？答案

【问题标题】：Why inline source maps?为什么要内联源映射？
【发布时间】：2015-02-24 14:34:57
【问题描述】：

今天我了解到可以将include source maps 直接添加到您的缩小 JavaScript 文件中，而不是将它们放在单独的 example.min.map 文件中。我想知道：为什么有人想做这样的事情？

对我来说拥有源映射的好处很明显：例如，可以在运行压缩文件时调试原始、非压缩源文件的错误。 最小化的好处也很明显：源文件的大小大大减小，浏览器下载速度更快。

那么考虑到地图的大小甚至比缩小后的代码本身更大，我到底为什么要将源地图包含到缩小文件中？

【问题讨论】：

是的，这似乎毫无意义！
也许 .map 扩展名未知，并为执行 .exe 和 .dll 文件的机器的管理员引发错误或问题？
我今天也了解到......在花了一个小时试图弄清楚为什么没有，然后发现它们已经嵌入到 .js 文件中......
源图用于开发目的。

标签： javascript gulp-sourcemaps

【解决方案1】：

我四处搜索，发现人们内联源地图的唯一原因是用于开发。内联源映射不应在生产中使用。

使用缩小文件内联源映射的理由是浏览器在开发和生产中解析完全相同的 JavaScript。像Closure Compiler 这样的一些缩小器不仅仅“只是”缩小代码。使用advanced options 它还可以执行以下操作：删除死代码、函数内联或激进的变量重命名。这使得缩小后的代码（可能）在功能上与源文件不同。

当然，这仍然可以通过引用外部源映射文件来完成，但有些人似乎更喜欢在构建过程中内联。

【讨论】：

今天发现一篇文章非常彻底地剖析了 sourcemaps 选项（主要用于 webpack）。很好的补充阅读来支持这个答案：survivejs.com/webpack/building/source-maps
我想知道是否还有运行时代码生成的用例？（浏览器会接受作为参数提供给new Function() 的内联源映射吗？）

【解决方案2】：

像Browserify 或Webpack 这样的JS 捆绑工具将捆绑您的所有.js 文件，输入一个或多个捆绑包，即使在开发模式下也是如此。因此在这种情况下，将内联源映射添加到生成的包中是帮助调试的最简单方法，而无需带来额外的文件。

【讨论】：

太棒了。我会试试的。你可能也解决了我的问题。 stackoverflow.com/questions/40199998/…

【解决方案3】：

在某些情况下，您可能希望将内联源映射包含到评估代码中。例如，您有一个 coffeescript 输入字段，并且您想启用在 coffeescript 中调试代码。在评估代码中有一个关于源映射的stackoverflow问题：

Getting source maps working with evaluated code

您可以在 cmets 中包含 @sourceURL 以指定 eval 代码的 URL 并加载映射文件（参见 SourceMap Spec 3 的第 8 页）。但并不总是可以将文件写入某个位置。

【讨论】：

【解决方案4】：

cheap-module-source-map 更适合生产环境。

inline-source-map 用于在测试时进行快速而肮脏的构建

【讨论】：

【解决方案5】：

如果您在 Android 设备上远程调试 Chrome，Chrome 调试器不能只访问设备上它想要的任何文件，并且包括单独的地图文件。如果您将它们包含在内，则不会出现此问题。

【讨论】：

没错，但是一旦文件大小翻倍，性能会受到怎样的影响？
你显然只会在开发中这样做
我不同意。如果您有 DTAP 设置，您还将获得带有测试和验收源图的缩小版本。甚至在生产环境中也允许在该环境中进行调试。在开发中，您不必使用缩小版本的 persé。包管理器允许为源映射创建一个单独的文件，您可以将其发送出去，这样您就不必将其包含在初始加载中以防止性能下降。
同样，Chrome 扩展 can't currently access the source maps 因此出于开发目的，有必要将它们内联到缩小文件中。

【解决方案6】：

如果您正在开发浏览器扩展，则 inline-source-map 是唯一的调试选项，因为扩展本身无法访问源映射文件——即使您可能必须在manifest.json（浏览器扩展的配置文件）。

【讨论】：