Das ist eine berechtigte Frage. Eine „Source Map“ ist eine spezielle Datei, die eine minimierte/entstellte Version eines Assets (CSS oder JavaScript) mit der ursprünglichen Autorenversion verbindet. Nehmen wir an, Sie haben eine Datei namens _header.scss, die in global.scss importiert wird, welches zu global.css kompiliert wird. Diese endgültige CSS-Datei wird im Browser geladen. Wenn Sie beispielsweise ein Element in den Entwicklertools inspizieren, wird Ihnen möglicherweise mitgeteilt, dass die <nav> display: flex; ist, weil es in Zeile 387 in global.css so steht.
page.css können wir feststellen, dass .meta position: relative; hat.Da diese endgültige CSS-Datei jedoch wahrscheinlich minimiert ist (alle Leerzeichen entfernt), wird uns in den Entwicklertools wahrscheinlich mitgeteilt, dass wir die gesuchte Deklaration in Zeile 1 finden! Unglücklich und nicht hilfreich für die Entwicklung.
Hier kommen Source Maps ins Spiel. Wie ich eingangs sagte, sind Source Maps spezielle Dateien, die die endgültige Ausgabedatei, die der _Browser_ tatsächlich verwendet, mit den Autoren-Dateien verbinden, mit denen _Sie_ tatsächlich arbeiten und Code in Ihrem Dateisystem schreiben.
Normalerweise sind Source Maps eine Konfigurationsoption des Präprozessors. Hier sind die Optionen von Babel. Ich glaube, dass Sie bei Sass nicht einmal ein Flag dafür in der Befehlszeile oder so übergeben müssen, da es standardmäßig Source Maps erzeugt.
Diese Source Maps sind also _für Entwickler_. Sie sind besonders nützlich für Sie und Ihr Team, da sie enorm bei der Fehlersuche und bei der täglichen Arbeit helfen. Ich benutze sie wahrscheinlich fast täglich. Ich würde sagen, _im Allgemeinen_ werden sie für die lokale Entwicklung verwendet. Sie könnten sie sogar mit .gitignore versehen oder sie im Bereitstellungsprozess überspringen, um weniger Assets in der Produktion zu liefern und zu speichern. Aber es gab kürzlich einige Diskussionen darüber, ob sie nicht auch in die Produktion gehen sollten.
Aber Source Maps wurden lange Zeit nur als Werkzeug für die lokale Entwicklung angesehen. Nichts, was man in die Produktion schickt, obwohl die Leute das auch getan haben, damit das Live-Debugging einfacher ist. Das allein ist schon ein guter Grund, Source Maps zu versenden. [...]
Zusätzlich hat Rails 6 gerade zugestimmt, Source Maps standardmäßig in der Produktion zu versenden, ebenfalls dank Webpack. Sie können diese Funktion deaktivieren, aber ich hoffe, das tun Sie nicht. Das Web ist ein besserer Ort, wenn wir anderen erlauben, aus unserer Arbeit zu lernen.
Sehen Sie sich diesen Issue-Thread an, um weitere interessante Gespräche über das Versenden von Source Maps in die Produktion zu finden. Die Vorteile lassen sich auf diese beiden Punkte reduzieren:
- Sie können Ihnen helfen, Bugs in der Produktion leichter zu finden.
- Sie helfen anderen Leuten, leichter aus Ihrer Website zu lernen.
Beides ist gut. Persönlich wäre ich dagegen, performanceoptimierten Code allein zu Lernzwecken zu versenden. Darüber habe ich letztes Jahr geschrieben.
Ich möchte meinen Quellcode nicht menschenlesbar haben, nicht aus Schutzgründen, sondern weil mir die Web-Performance wichtiger ist. Ich möchte, dass meine Website mit Lichtgeschwindigkeit auf einem winzigen Staubkorn eines magischen Netzwerkpakets ankommt und sich zu einer vollständigen Website entfaltet. Oder was auch immer die Informatik als den absolut schnellsten Weg ansieht, Websitedaten zwischen Computern zu senden. Ich mache mir mehr Sorgen um den Zustand der Web-Performance als um die Web-Bildung. Aber selbst wenn ich mir große Sorgen um die Web-Bildung machen würde, glaube ich nicht, dass es die Aufgabe des Netzwerks ist, Lehrbarkeit zu liefern.
Das Versenden von Source Maps in die Produktion ist ein guter Mittelweg. Es gibt keine Auswirkungen auf die Performance (Source Maps werden nur geladen, wenn Sie die Entwicklertools geöffnet haben, was meiner Meinung nach für eine echte Performance-Diskussion irrelevant ist) mit dem Vorteil, Debugging- und Lernvorteile zu bieten.
Die Nachteile, die in der jüngsten Diskussion angesprochen wurden, lassen sich auf Folgendes reduzieren:
- Sourcemaps erfordern Kompilierungszeit.
- Es erlaubt Leuten, ich weiß nicht, Ihren Code zu stehlen oder so etwas.
Auf #2 lege ich keinen Wert (tut mir leid), und #1 scheint für eine kleine oder das, was wir als durchschnittliche Website betrachten, im Allgemeinen vernachlässigbar zu sein, obwohl ich befürchte, dass ich für Mega-Websites keine Aussage treffen kann.
Eine Sache, die ich noch hinzufügen sollte, ist, dass Source Maps sogar für CSS-in-JS-Tooling generiert werden können. Für diejenigen, die Stile buchstäblich in das DOM für Sie einfügen, werden diese Source Maps auch eingefügt. Ich habe in diesen Situationen _deutliche Verlangsamungen_ gesehen, daher würde ich sagen, dass Sie Source Maps definitiv _nicht_ in die Produktion versenden sollten, wenn Sie sie nicht aus Ihren Haupt-Bundles auslagern können. Andernfalls würde ich stark dafür stimmen, dass Sie es tun.
Eine Lösung dafür, die es Ihnen erlaubt, Beides zu haben, ist, den Zugriff auf die .map-Dateien zu kontrollieren, so dass sie nur über das Intranet Ihres Unternehmens oder eine bestimmte IP-Adresse zugänglich sind, oder die .map-Datei einfach nicht in der Produktion bereitzustellen, bis Sie sie benötigen (weniger sicher).
Eine andere wäre, die generierten Sourcemaps-Links auf localhost verweisen zu lassen und dann die Sourcemaps von Ihrem eigenen Rechner aus "beizustellen". Das können Sie mit Webpack tun.
Schließlich können Sie, wenn Sie Chrome verwenden, Dateien ohne den Sourcemap-Link in der Produktion bereitstellen und dann lokale Überschreibungen verwenden, um die Links wieder hinzuzufügen, wenn Sie sie benötigen.
Ehrlich gesagt, das ist alles zu aufwendig, als mir lieb ist. Ich erinnere mich, als Sourcemaps für Chrome Dev Tools herauskamen, konnte man mit der rechten Maustaste auf eine .js-Datei klicken und "Sourcemaps laden" wählen, was dann einen Dateidialog öffnete, um Ihre .map-Datei auszuwählen. Das ist meiner Meinung nach am einfachsten.
Hier ist ein guter Artikel, der sich näher mit dem Thema beschäftigt: https://itnext.io/using-sourcemaps-on-production-without-revealing-the-source-code-%EF%B8%8F-d41e78e20c89
Das. Außerdem unterstützen viele moderne Instrumentierungstools private Sourcemaps. Das bedeutet, dass Ihre clientseitigen Stack-Traces, wenn sie von diesen Tools/Diensten gesammelt und verarbeitet werden, Ihnen viel mehr Informationen viel schneller liefern.
Ich habe nie darüber nachgedacht, ob ich Sourcemaps in die Produktion versenden soll oder nicht. Ich genieße die Vorteile davon in der lokalen Entwicklung, und sie werden in Git nicht ignoriert, also werden sie immer versendet, und ich sehe darin eigentlich kein Problem.
Es gibt nicht wirklich eine Möglichkeit, dass jemand etwas anderes stehlen kann als ein paar CSS-Tricks (kein Wortspiel) oder JS-Hackereien. Sie bräuchten immer noch den Backend-Code (PHP oder anders), damit etwas tatsächlich funktioniert.
Und darüber hinaus wäre es einfacher, Probleme zu diagnostizieren, wenn einige Ihrer Benutzer/Kunden Probleme haben, da Sie den genauen JS/CSS sehen können, der auf dem Live-Server Probleme verursacht.
Interessanter Gedanke trotzdem :)
Ja. Das tun Sie. Langsamere Build-Zeiten sind in Ordnung, wenn das bedeutet, dass die Zeit zur Lösung eines großen Problems erheblich verkürzt wird.
Ich stimme zu, dass Sourcemap-Dateien in der Produktion bereitgestellt werden sollten. Wenn man sich Sorgen macht, seinen "echten Code" zu zeigen, hat Webpack eine Funktion, um die Sourcemap-Dateien auf einem externen Server zu hosten. So kann man sie irgendwo platzieren, wo eine Autorisierung erforderlich ist.
https://webpack.js.org/plugins/source-map-dev-tool-plugin#host-source-maps-externally
Wenn Sie einen Chef haben, wie ich ihn hatte, der den Produktionscode auf dem Live-Server bearbeitet, sind Sie wirklich auf Sourcemaps angewiesen, wo immer möglich.
Drucken Sie sie für die Notfall-Fehlersuche unterwegs aus.
Ich übertrage einfach alle Quellen, unverändert, per FTP auf die Produktionssysteme und wende einige Filter an, um zu vermeiden, dass Produktionseinstellungen überschrieben werden. Daher ist keine Build-Kette oder Sourcemaps erforderlich.
Source Maps für JS sind auch wichtig für die Fehlerverfolgung, da Tools wie Sentry sie verwenden können, um den ursprünglichen Code-Speicherort aus dem Exception-Backtrace anzuzeigen.
Sie sollten immer Map-Dateien haben, besonders wenn Sie in der Produktion arbeiten. Aber es gibt einen Unterschied zwischen dem Haben von Map-Dateien und dem öffentlichen Freigeben derselben.
Aus meiner Erfahrung ist es am besten, sie in einer separaten .map-Datei zu haben und dann den Zugriff auf diese Datei zu beschränken. Meine Webpack-Konfiguration setzt alle .map-Dateien als privat beim Hochladen in meinen AWS S3 Bucket. Ich muss mich erst bei AWS anmelden, um dann aus dem Browser auf die besagten Dateien zugreifen zu können.
Ich protokolliere auch clientseitige JS-Fehler und lade den Stacktrace auf einen Reporting-Server hoch. Von dort aus habe ich ein Node-Skript, das die .map-Datei mit den richtigen Anmeldedaten abruft und mir die korrekte Zeile und Datei nennt.
Vielleicht irre ich mich, aber ich nahm an, dass Source Maps nur heruntergeladen werden, wenn Sie sie einbetten oder in den Entwicklertools des Browsers anzeigen. Andernfalls haben sie keine Auswirkungen auf die Webseite, sodass keine Leistungseinbußen auftreten sollten, abgesehen von den wenigen Zeichen, die zum Referenzieren der .map-Datei verwendet werden.
Angesichts der Tatsache, dass wir oft Bugs beheben müssen, die nur in der Produktion auftreten, sind sie ein unschätzbares Werkzeug, das unabhängig von der Umgebung immer verwendet werden sollte.