为什么内联源地图？

Question

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

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

那么为什么在地球上我会想要将源地图包含在缩小的文件中，因为地图的大小甚至比缩小的代码本身还要大？

Answer 1

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

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

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

Answer 2

如果您在Android设备上远程调试Chrome，则Chrome调试器不仅可以访问设备上所需的任何文件，还包括单独的地图文件。如果你将它们包括在内，你就不会遇到这个问题。

Answer 3

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

Answer 4

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

Getting source maps working with evaluated code

您可以在评论中包含@sourceURL，以指定您的评估代码的网址并加载地图文件（请参阅SourceMap Spec 3的第8页）。但是并不总是可以将文件写入某个位置。

Answer 5

cheap-module-source-map对于生产构建来说要好得多。

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

Answer 6

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