为什么内联源地图？ [英] Why inline source maps?

问题描述

今天我了解到可以将包含源地图直接导入到缩小的JavaScript文件中，而不是将它们放在一个单独的example.min.map文件中。我想知道：为什么有人想做类似的事情？

Today I learned that it is possible to include source maps directly into your minified JavaScript file instead of having them in a separate example.min.map file. I wonder: why would anybody want to do something like that?

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

The benefit of having source maps is clear to me: one can for example debug errors with the original, non-compressed source files while running the minified files. The benefit of minimization is also clear: the size of source files is greatly reduced, making it quicker for browsers to download.

为什么选择地球我想将源地图包含在缩小的文件中，因为地图的大小甚至大于缩小的代码本身？

So why on Earth I would want to include the source maps into the minified file, given that the maps have size even greater than the minified code itself?

推荐答案

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

I searched around and the only reason I could see that people inline source maps is for use in development. Inlined source maps should not be used in production.

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

The rational for inlining the source maps with your minified files is that the browser is parsing the exact same JavaScript in development and production. Some minifiers like Closure Compiler do more than 'just' minify the code. Using the advanced options it can also do things like: dead code removal, function inlining, or aggressive variable renaming. This makes the minified code (potentially) functionally different than the source file.

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

This could still be done by referencing external source map files of course, but some people seem to prefer inlining for their build process.

这篇关于为什么内联源地图？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！