Dies entfernt Kommentare und überflüssigen Leerraum, und sonst nichts. Es durchläuft den Quelltext und verfolgt dabei Zeichenketten, Template-Literale, Literale regulärer Ausdrücke und beide Kommentarformen, sodass ein Kommentar nur dort entfernt wird, wo er wirklich einer ist — ein doppelter Schrägstrich in einer Zeichenkette oder einem regulären Ausdruck bleibt unangetastet, und darin liegt der Unterschied zwischen funktionierendem Code und einer kaputten Datei.
Zeilenumbrüche bleiben bewusst erhalten. JavaScript setzt unter bestimmten Bedingungen Semikola an Zeilenumbrüchen ein, Code ohne abschließende Semikola ändert also seine Bedeutung, wenn die Umbrüche zusammengezogen werden. Sie zu behalten kostet etwas Größe und beseitigt eine ganze Fehlerklasse. Kommentare, die mit einem Ausrufezeichen beginnen, bleiben stehen, denn das ist die Konvention für Lizenzhinweise.
Die Grenze, klar benannt
-
Nichts wird umbenannt:
Ein echter Minifier kürzt Variablennamen, und daher stammt der größte Teil der Ersparnis in einem Produktionsbundle. Das sicher zu tun erfordert einen vollständigen Parser und ein Scope-Modell, und ein feiner Fehler dabei erzeugt eine Datei, die nicht hier, sondern im Produktivbetrieb versagt.
-
Kein toter Code wird entfernt und kein Ausdruck umgeschrieben:
Die Ausgabe ist Ihr Code ohne Kommentare und Einrückung. Erwarten Sie eine brauchbare Verkleinerung, nicht das Verhältnis, das ein Build-Werkzeug erreicht.
-
Für einen echten Build nehmen Sie einen echten Bundler:
esbuild, terser oder SWC benennen um und entfernen ungenutzten Code. Dies hier ist für ein Codestück, ein eingebettetes Skript oder eine Datei ohne Build-Schritt.
-
Bei Mehrdeutigkeit bewusst zurückhaltend:
Ob ein Schrägstrich einen regulären Ausdruck beginnt oder dividiert, lässt sich ohne Parsen nicht entscheiden. Die Heuristik hier ist für die praktisch vorkommenden Formen korrekt, und wo sie unsicher ist, lässt sie den Code, wie er ist.
What it actually removes: comments and whitespace, nothing more
The [msm_tool slug="js-minifier"] walks the source tracking strings, template literals, regular expression literals and both comment forms, so a double slash sitting inside a string or a regular expression is left alone rather than mistaken for the start of a comment. That distinction is the difference between a working file and one where `"https://example.com"` loses everything after the second slash.
Newlines stay, on purpose
JavaScript inserts semicolons at line breaks under certain conditions, so code written without terminating semicolons changes meaning the moment its newlines are collapsed away. Keeping every line break costs a little size and removes an entire category of failure that a naive whitespace collapse would otherwise introduce.
Licence comments are recognised, not just kept by accident
A comment beginning with an exclamation mark is preserved specifically, since that is the established convention for a licence header. Every other comment is removed, but this one exception exists because stripping a required licence notice is a different kind of mistake from stripping an ordinary code comment.
Where the ambiguous slash is handled conservatively
Whether a slash begins a regular expression or performs division cannot be decided with certainty without actually parsing the surrounding code. The heuristic used here is correct for the forms that show up in practice, and wherever it is genuinely unsure, it leaves the code exactly as written rather than guessing and risking a break.
Nothing is renamed, and that is most of the missing saving
A real production minifier shortens variable and function names, which is where most of the size reduction in a built bundle actually comes from — and doing that safely needs a full parser and a scope model, since getting it subtly wrong produces code that fails only after it ships. This tool does not attempt it, so the reduction here is real but modest: comments and indentation gone, nothing structural changed.
Where a real build tool is the right choice instead
Anything with an actual build step is better served by esbuild, Terser or SWC, which perform the renaming and dead-code elimination this deliberately does not. This is built for the opposite case: a standalone snippet, an inline script, or a file with no build pipeline behind it at all.