On 05/18/2010 08:53 AM, Michael Dale wrote:
But in general its probably better / easier for end users to just identify their platform and whats not working, since its all code to them anyway. If they are a developer or are going to do something productive with what they are seeking they likely have the code checked out locally and use the debug mode.
The problem here is Wikimedia sites. If you leave the debug mode off and serve fully minified scripts on WMF sites, the hundreds if not thousands of people who develop user/site scripts for them will have a very hard time debugging anything that involves interactions with the minified code. If you turn debug mode on permanently, you lose most of the benefit of having a minifier to begin with (Wikimedia being the single biggest user of MediaWiki).
Then there's also the problem that the MediaWiki environment on Wikimedia sites can be quite different from a stock install, and duplicating enough of it on a test wiki to be able to reproduce a Wikimedia-specific bug may be quite difficult -- particularly so if you have to do this before you even know where the bug occurs, because you couldn't do any useful debugging due to the code being minified.
I'd like to second Aryeh's suggestion to at least tweak the minifier to leave newlines intact (although collapsing multiple consecutive newlines to one would be OK, I guess). That way users could at least set up useful breakpoints and receive error messages that tell more than which file the problem occurred in.
(Part of the blame here goes to the debuggers, of course. If common JavaScript debugging tools like Firebug could do things like expand minified code and set up breakpoints on individual statements rather than just lines, minification would be much less of a problem for debugging. But currently, as far as I know, they don't.)