nicht angemeldet
Wir reden über den hypothetischen Fall, dass ein Fehler im Produktivsystem reproduziert werden kann, aber nicht im Entwicklungssystem. Wenn das der Fall ist, dann sollten beide zunächst (abgesehen vom gepackten JS-Code) so angeglichen werden, dass der Fehlerfall auch im Entwicklungssystem auftritt. Wenn das nicht weiterhilft, dann bringt auch nicht-gepackter JS-Code nichts, es sei denn, der Fehler liegt in der Komprimierung selbst.
Insofern halte ich den Fall für sehr unwahrscheinlich und wenn der Fehler nicht durch die Komprimierung kommt, ist auch nicht damit geholfen, dass man beim Produktivsystem unkomprimierten Code verwendet.
Es sind übrigens auch Zwischenlösungen möglich: Beispielweise kann man alle Kommentare und unnützen Whitespace entfernen, aber die Zeilenumbrüche und Variablennamen intakt lassen. Das reduziert zwar den Geschwindigkeitsgewinn, lässt dafür aber sinnvolle Fehlermeldungen zu.
Man ist ja nicht komplett »blind« bei bem Debuggen von Minified-Code. Wenn man den eigenen Code kennt, kann man mit Fehlermeldungen und Stack-Traces durchaus etwas anfangen. Es muss ja nur reichen, den Fehler zu lokalisieren. Wenn man ordentlich strukturierten Code schreibt, ist das auch kein Problem. Außerdem sind die wenigsten Scripte nach dem Minifying komplett unleserlich. Umbenannt werden bloß lokale Variablen, es bleiben meist genug »öffentliche« Eigenschaft und Methoden übrig, sodass der Zusammenhang weiterhin erkennbar ist.
Die Frage ist aber, ob sich das Packen wirklich lohnt, da in vielen Fällen nicht das Parsen des Skriptcodes der Flaschenhals sein dürfte (ich lasse mich da aber von Messungen gern eines besseren belehren).
Natürlich gibt es keinen großen Unterschied zwischen einem GZip-komprimierten Script mit nur wenig gekürztem Code und einem ebenfalls GZip-komprimierten Script mit vollständig gekürztem Code.
Mathias