6

Source maps are very helpful for debugging minimized scripts or translated languages (ex. CoffeeScript) but the browser gives you very little output to troubleshoot why your mapping doesn't work. Does anyone have a checklist that can be used to find where your mapping goes wrong. Right now I have the setup working on my local development environment but when trying to deploy it to our staging server "it doesn't work".

Things I have verified are same between my local and the staging environment:

  1. Source maps are enabled in the inspector settings
  2. The package.min.js file is served from /js
  3. The package.min.js contains the same //@ sourceMappingURL=package.min.js.map line
  4. The minified source + source map generated by uglify-js2
  5. The original files are accessible in /js

One difference I can see is that the size of the generated source map is slightly different and the file in the sources attribute of the sourcemap hash has a slightly different ordering. But the source map is quite large so it's not trivial to verify that it actually isn't different in a significant manner.

Sam
  • 14,642
  • 6
  • 27
  • 39

1 Answers1

1

Source maps (and original source files) are fetched over HTTP. Look at your server logs to see what the browser is actually requesting.

Also: The //@ is going to be replaced with //#.

Craig Stuntz
  • 125,891
  • 12
  • 252
  • 273
  • 2
    I want to emphasize that that change is in the future. The version of uglify that is currently being used by the [grunt task](https://npmjs.org/package/grunt-contrib-uglify), outputs the new `//#` format but the current version of Chrome (27.0.1453.116) seems to only support the old `//@` format. It was driving me crazy until I figured that out. – Useless Code Jul 06 '13 at 09:23