I hope the the developers of these obfuscators are reading this…because I have a proposed solution to the problem.
Now, I want to start out by mentioning that I fully understand why obfuscators exist for reasons such as source code protection and decreasing download size. What I propose takes this fully into account, yet makes your library developer friendly in a secure way:
During the obfuscation process create an index file that maps each variable, function and class to a real line number and store this file in a web folder. Then create a small html file that lets you search the index and return the real line number. Provide an option for return the variable, function or class name, too.
The concept is that if there is an error, like the “z=null line 14300” I mentioned above, developers can then at least have some hope of narrowing down the general area of the code where it might be occurring.
The bonus is, if you own an obfuscated commercial library, now your tech support people can also look up the general area where a customer might be having a problem. For security reasons you don’t have to share the index file, But, even then, there isn’t enough information in it to de-compile the library. Now, if I post my error to the forum: What is “z=null line 14300”? Tech support will be able to tell me that I’m missing a custom property on a widget’s HTML DIV element. It’s a win-win situation.
What do you think?