Wenn Sie ein Softwareentwickler sind, dann wissen Sie wahrscheinlich schon, dass eine Ihrer vielen Rollen definitiv nicht darin besteht, ein weiterer Raderfinder zu sein. Zumindest nicht in den meisten Fällen.
Ich würde gerne über Folgendes schreiben JavaScript Abhängigkeiten. Aber lassen Sie uns von vorne beginnen. Wenn Sie ein Softwareentwickler sind, dann wissen Sie wahrscheinlich schon, dass eine Ihrer vielen Rollen definitiv nicht darin besteht, ein weiterer Rad-Erfinder zu sein. Zumindest nicht in den meisten Fällen. Die Welt ist weit genug fortgeschritten, um sagen zu können, dass es heute Pakete für fast alles gibt, die unsere Entwicklung einfacher und effizienter machen.
Dies ist natürlich keine Ermutigung, das Interesse an anderen Themen zu verlieren - jedes Paket hat einen ziemlich großen Spielraum, um sich zu verbessern und weiterzuentwickeln. Ihr Unternehmensziel ist es jedoch, eine vollständige Produkt auf einem Teller pünktlich oder sogar noch bevor er fertig ist. Pakete helfen Ihnen, diese Pläne zu verwirklichen, indem sie npm oder Garn auf der Liste Ihrer besten Freunde ganz oben stehen, aber seien Sie sich bewusst: Jede Lösung, auch diese, kann auch Risiken mit sich bringen. Und wir werden versuchen, sie zu beschreiben und Ihnen im folgenden Artikel einen besseren Weg zu zeigen, wie Sie sie umgehen können.
Lassen Sie uns mit einer Geschichte beginnen...
Stellen Sie sich ein großes JavaScript vor Projekt. Die geschäftlichen Anforderungen zwingen die Entwickler, ein bestimmtes Paket zu verwenden, das eine ordnungsgemäße Integration mit einem anderen System eines Kunden ermöglicht. Und das ist völlig in Ordnung. MVP pünktlich geliefert wurde, der nächste Vertrag unterzeichnet wurde und die Entwicklung fortgesetzt wird. Der Kunde bittet darum, den nächsten Teil eines Systems zu integrieren, für den Ihr Paket aktualisiert werden muss.
Dieser Teil geht gut, bis die Tests abgefeuert werden. Es scheint, dass das Paket einen einfachen, aber unbequemen Fehler enthält, der noch in keiner Produktversion behoben wurde, und es ist bekannt, dass dies nicht so bald geschehen wird. Sie können nicht einfach Ihre Knoten_Module Verzeichnis - sollte es aus dem Repository entfernt werden, so dass Ihre Mitarbeiter nie etwas von Ihren Änderungen erfahren! Nun, während Sie dies gelesen haben, haben Sie wahrscheinlich schon verstanden, was zu tun ist - forken. Aber brauchen Sie wirklich einen solchen Hammer?
Verstehen Sie Ihr Problem
Sie müssen sich darüber im Klaren sein, ob das Problem, mit dem Sie konfrontiert sind, nur Sie oder eine größere Gemeinschaft betrifft. Manchmal wird das Fehlen einer bestimmten Funktion als Fehler interpretiert, was nicht immer richtig ist. Deshalb, Ihre Lösung wird möglicherweise nicht von einer Gemeinschaft akzeptiert und nicht in ein offizielles Repository aufgenommen.. Sie brauchen es aber trotzdem hier und jetzt. Also, auf geht's!
Laut den Veröffentlichungshinweisen des Github-Repositorys ist das Patch-Paket ) wurde im Mai 2017 offiziell veröffentlicht. It ist ein leistungsfähiges Werkzeug, das es ermöglicht, Änderungen innerhalb des Abhängigkeitsprojekts in Ihrem Knoten_Module Verzeichnis. Einige mögen sagen, dass dies ein ziemlicher Irrsinn ist - der Installationsbefehl Ihres Abhängigkeitsmanagers wird die Änderungen überschreiben.
Nun, das ist richtig. Allerdings koexistiert ein Patch-Paket mit npm und Garn perfekt (ich muss zugeben, dass es mit npm bisher etwas besser funktioniert, Sie können mehr im Abschnitt "Warum sollten Sie postinstall-prepare mit Yarn verwenden?" in der README-Datei lesen) und nutzt den vollen Vorteil einer Skriptvorbereitung ("script": {"prepare":""}) Ihrer paket.json Datei. Patch-package erstellt buchstäblich ein Diff-Verzeichnis zwischen Ihren Änderungen und dem Originalpaket, das im Patch-Ordner Ihres aktuellen Projekts gespeichert wird.
Nach dem Ausführen des Installationsbefehls und dem Herunterladen aller Abhängigkeiten wird dieser Unterschied auf das Projektverzeichnis angewandt, so dass Ihre Änderungen für alle Mitwirkenden perfekt rekonstruiert werden. Das macht Ihr Leben einfacher, nicht wahr? Die Lösung hat aber auch einige Nachteile. Das Patch-Paket kann keine Abhängigkeiten Ihres Pakets reparieren oder Änderungen in paket.json.
In diesem Fall können Sie die Fork-Lösung verwenden. Außerdem müssen Sie die Anzahl der Änderungen berücksichtigen, die Sie in Ihr Abhängigkeitspaket übernehmen wollen, und ob diese mit der Zeit wachsen werden. Falls dies der Fall ist, sollten Sie sich die Verwendung von fork gut überlegen, da es sich um Ihr eigenes Projekt handelt.
Seien Sie nicht egoistisch!
Patches sind eine großartige Möglichkeit, Abhängigkeiten zu beheben, ohne endlose Forks zu erstellen und mehrere Projektquellen zu erzeugen. Aber Sie sollten immer daran denken, dass die Nutzung der Community nicht nur in eine Richtung gehen sollte. Wenn Sie einen Fehler finden oder das Gefühl haben, dass Sie das Paket, das Sie verwenden, verbessern können, sollten Sie immer in Betracht ziehen, anderen zu helfen, indem Sie einen Fehler melden oder sogar zum Projekt beitragen!