Last modified: 2011-06-04 18:48:18 UTC
Created attachment 7709 [details] Minified file is edit_calend.modules.mini.js, simple minification code is in JobSchEd.loader.php I might be wrong but currently I see no way to tweak the resource loader to my preferences (except for the debug mode). I would like to be able to use this kind of options (in Local Setting, but setting a user preference for this would also be nice for debugging): $wgRLRemoveVerticalWhiteSpace = true/false; $wgRLRemoveHorizontalWhiteSpace = true/false; $wgRLRemoveInlineComments = true/false; $wgRLRemoveMultiComments = true/false; Also when not removing horizontal whitespace (new lines) it would be nice to add comments marking end of multi-line comments (IIRC this was requested on wikitech-l). I have a simple working code for concatenation & adding comments that I'm attaching. Not sure if this will be useful, but have a look at parseMultiCom method of ecSimpleJSLoader. An example minified file also attached in the package.
Maybe you could help me understand the use case for this. I am personally opposed to adding unnecessary complexity and configuration to software, so if there's not a strong use case for it, that constitutes a strong argument against it. I am also against the changes that have been made to JSMin.php recently which remove all white-space except for new lines (horizontal only, as you are calling it here). My argument is that there should be 2 modes, debug off and debug on. * Debug off should be as high performance as possible (stripping every non-critical character, combining when appropriate, gzip compressed, etc.) * Debug on should be as easy for developers as possible (keeping line and character offsets accurate, never combining, etc.) Anything between these two extremes will neither server production nor development well enough to have any value.
(In reply to comment #1) > Maybe you could help me understand the use case for this. I am personally > opposed to adding unnecessary complexity and configuration to software, so if > there's not a strong use case for it, that constitutes a strong argument > against it. > > I am also against the changes that have been made to JSMin.php recently which > remove all white-space except for new lines (horizontal only, as you are > calling it here). > > My argument is that there should be 2 modes, debug off and debug on. > > * Debug off should be as high performance as possible (stripping every > non-critical character, combining when appropriate, gzip compressed, etc.) > * Debug on should be as easy for developers as possible (keeping line and > character offsets accurate, never combining, etc.) > > Anything between these two extremes will neither server production nor > development well enough to have any value. I totally agree with this entire comment.
Use case is attached ;-). I prefer to have documentation removed to avoid unnecessary load for all users (including those debugging code) and still be able to get a line number of the original code. Yes you will probably say this won't happen for Wikipedia, but I'd like to have such an option e.g. for my office wiki. Currently I had to write my own loader.
Removing documentation only, as you are wanting to do, will not preserve line numbers. The first resource (there can be many resources in a module) in the first module (there can be many modules in a request/response) could have matching line numbers, but every resource after that will not. You must use ?debug=true in the URL of the page or $wgResourceLoaderDebug = true in your LocalSettings.php file to achieve matching line numbers. This will bypass all minification and combination steps, resulting in responses which are easier for developers to work with. Again, this mixed approach does not solve your use case as well as debug=true, thus the middle-ground approach being suggested here is not worth the complexity.
I'm not saying I'm preserving line numbers. But the code changes: /* something */ to // EOC@line[original line number] So I can go to the line number very fast, but I also can view the code and see what is wrong. I can also debug it without switching to debug mode while still having one file instead of many and (in my case) even after simple minification the file is almost 40% shorter (yes I write excessive comments ;-)).
Please see my wikitech-l post about this. http://lists.wikimedia.org/pipermail/wikitech-l/2010-September/049725.html
In production mode files are combined into a single request. Whether or not the amount of lines is preserved doesn't help since the files are combined into one. I have yet to see the first major minification system that keeps in mind debugging processes as that's sortof the opposite of attempting to serve files as quickly and effeciently as possible. debug=true mode will serve each individual file seperately (like it used to be before resource loader), I think if you expect a bug reporter to be able to get an actual line number from a particular file, expecting them to append debug=true to the URL should not be a problem. Marking as WONTFIX since this is not the intention of production mode.
