Why inline source maps?

Solution 1:

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 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.

Solution 2:

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.

Solution 3:

JS bundling tools like Browserify or Webpack will bundle all your .js files 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.

Solution 4:

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:

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.