idea: a sane way to strip logger/debug code

[jeffContext]

Here's an idea for a relatively safe way to strip out logger statements and debug code from javascript in production mode. A jammit user would wrap debug code in a comment like this:

/*DEBUG  debugDoSomethingHeavy(); DEBUG*/

For production mode, the above would be removed automatically when the compressor strips out comments, as normal. In development mode, however, jammit would globally strip \/DEBUG and DEBUG\\/ before serving each javascript file, leaving the desired debug code to run.

[jashkenas]

This is a great idea -- but isn't something that should be built-in to Jammit. You can perfectly well add flags to strip out debugging code yourself -- whether that means turning them off in JavaScript, overriding console.log with a no-op, or rewriting the packaged javascript files without those blocks of code...

Lots of folks have different solutions for handling debugging in production, and I don't think that Jammit should force a particular way of doing it.

[jeffContext]

Ok, that makes sense.

I got my stuff working by adding a custom class to the Rack.

Btw, no-op for console.log would only partially help. The expression is still evaluated and it doesn't solve debug code that manipulates the DOM.

A nice feature for you to consider for Jammit would be before/after filters. Much less work then adding custom middleware. And it would permit a wide range of other devious behaviors. :) Eg., adding a copyright notice or versioning/meta notes after compression.

[jashkenas]

Sure -- if you'd like to rework your module to use filters instead of middleware, I'd be glad to take a Jammit patch that provides those hooks...

[jeffContext]

That was my first instinct, but it would involve changing more Jammit files than I'm comfortable doing.

Initial thoughts on what's needed:

• The Jammit::Helper would at times send non-packaged assets to Jammit::Controller, perhaps via a new route. (So filters could be applied in dev mode.)
• In assets.yml, the user would optionally specify on any package the names of the JammitFilter classes they want applied. The jammit controller would instantiate these.
• ActionController#after_filter shouldn't be used because it would bypass caching. Instead, the jammit controller should probably call before_packing and after_packing methods if they exist on the JammitFilter. It would get passed some context (path, jammit config, etc) so it could make a smart decisions about what to do

The above seems a little to deep for me to take on right now. But I'd be happy to share the quick & dirty Rack solution that I whipped up. Is there a wiki somewhere? (looks disabled on github.) Or want me to add it to a contrib/ directory?

[jashkenas]

Really, just blogging about it somewhere would be best. Or putting it in a gist... Then paste the link in this issue.