javascript 为什么要内联源映射？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/27671390/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why inline source maps?
提问by Akseli Palén
Today I learned that it is possible to include source mapsdirectly 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?
今天我了解到可以将源映射直接包含在您缩小的 JavaScript 文件中，而不是将它们放在单独的 example.min.map 文件中。我想知道：为什么有人想做这样的事情？
The benefit of having source maps is clearto 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?
那么为什么我想将源地图包含到缩小的文件中，因为地图的大小甚至大于缩小的代码本身？
采纳答案by pseudosavant
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.
我四处搜索，我看到人们内联源映射的唯一原因是用于开发。不应在生产中使用内联源映射。
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 Compilerdo more than 'just' minify the code. Using the advanced optionsit 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.
使用缩小的文件内联源映射的原因是浏览器在开发和生产中解析完全相同的 JavaScript。一些像Closure Compiler这样的缩小器不仅仅“只是”缩小代码。使用高级选项，它还可以执行以下操作：死代码删除、函数内联或积极的变量重命名。这使得缩小的代码（可能）在功能上与源文件不同。
This could still be done by referencing external source map files of course, but some people seem to prefer inlining for their build process.
当然，这仍然可以通过引用外部源映射文件来完成，但有些人似乎更喜欢内联他们的构建过程。
回答by Tim
If you are remote debugging Chrome on an android device, the Chrome debugger cannot just access any file it wants on the device and that includes separate map files. If you include them inline you don't have this issue.
如果您在 android 设备上远程调试 Chrome，Chrome 调试器不能只访问设备上它想要的任何文件，包括单独的地图文件。如果您将它们内联包含在内，则不会出现此问题。
回答by jasonslyvia
JS bundling tools like Browserifyor Webpackwill bundle all your .jsfiles input one or several bundles, even in developing mode. So in this case, adding inline source map to generated bundles is the easiest way to help debugging without bringing extra files.
JS 打包工具就像Browserify或Webpack将把你所有的.js文件打包成一个或几个包，即使在开发模式下也是如此。所以在这种情况下，将内联源映射添加到生成的包中是帮助调试而不带额外文件的最简单方法。
回答by Helicase
In some situations you might want to include inline sourcemaps into evaluated code. E.g you have a coffeescript input field and you want to enable debbuging the code in coffeescript. There is a stackoverflow question about source maps in evaluated code:
在某些情况下，您可能希望将内联源映射包含到评估代码中。例如，您有一个coffeescript 输入字段，并且您希望在coffeescript 中启用调试代码。评估代码中有一个关于源映射的计算器溢出问题：
Getting source maps working with evaluated code
You could include @sourceURL in your comments to specify a URL of your eval code and load a map file (see page 8 of SourceMap Spec 3). But it is not always possible to write files to some location.
您可以在注释中包含 @sourceURL 以指定 eval 代码的 URL 并加载映射文件（请参阅SourceMap Spec 3 的第 8 页）。但是并不总是可以将文件写入某个位置。
回答by Carl
cheap-module-source-mapis much better for a production build.
cheap-module-source-map对于生产版本来说要好得多。
inline-source-mapis used to make quick and dirty builds when testing
inline-source-map用于在测试时进行快速而肮脏的构建
