I noticed a commit from Anis to generate a "debug" version of something from browserify. This generates a "sourcemap" which debuggers can read show you your original source from a transformed JavaScript file.
https://github.com/apache/cordova-js/commit/4e674c34422fb529fd2f553af8fb1c38deb9de74 YAY! I've been pretty happy with the sourcemap support in Chrome. I hope it works well with other browsers. One thing though. What happens when you use the debug option with browserify is that it creates the same file as it would when you don't use browserify, then appends a debug wad to it. That thing is actually quite large. That's why you create non-debug and debug versions. But you can do it differently. There's a thing with sourcemaps where you can, instead of appending a big blob to the end of your JS, you insert a link to the blob (usually relative). This link is small, it's a link. So, you can actually use one of those style of sourcemap'd js file for both production and debug. You just add the debug file, or make it available via the link, when you want to debug. I've written up my "best practices" for sourcemaps here, which hopefully explains some of this more. http://pmuellr.blogspot.com/2013/10/sourcemap-best-practices.html I also have a tool called cat-source-map, which can split the debug junk out of a debug browserify file into a separate file, and replace it with a link. https://npmjs.org/package/cat-source-map Honestly don't know if this will be useful or not, maybe it's easier for folks to have separate debug and production js, but figured I'd chime in. And if you're going to browserify, might as well uglify as well, but I'd not use the --mangle option. There is an example, I think of using sourcemaps, uglify, and browserify working together in the cat-source-map tests. A little tricky. -- Patrick Mueller http://muellerware.org
