cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Mueller <>
Subject browserify / debug
Date Fri, 07 Feb 2014 00:03:11 GMT
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.


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.

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

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message