Αν είστε προγραμματιστής λογισμικού, τότε πιθανώς γνωρίζετε ήδη ότι ένας από τους πολλούς ρόλους σας δεν είναι σίγουρα να είστε ένας ακόμη εφευρέτης τροχών. Τουλάχιστον, όχι στις περισσότερες περιπτώσεις.
Θα ήθελα να γράψω για JavaScript εξαρτήσεις. Αλλά ας ξεκινήσουμε από την αρχή. Εάν είστε προγραμματιστής λογισμικού, τότε πιθανώς γνωρίζετε ήδη, ότι ένας από τους πολλούς ρόλους σας δεν είναι σίγουρα να είστε ένας ακόμη εφευρέτης τροχών. Τουλάχιστον, όχι στις περισσότερες περιπτώσεις. Ο κόσμος έχει προχωρήσει αρκετά, ώστε να πούμε ότι σήμερα υπάρχουν πακέτα για σχεδόν τα πάντα, που κάνουν την ανάπτυξή μας πιο εύκολη και αποτελεσματική.
Αυτό φυσικά δεν αποτελεί ενθάρρυνση για απώλεια ενδιαφέροντος για άλλα θέματα - κάθε πακέτο έχει αρκετά μεγάλο χώρο για να βελτιωθεί και να εξελιχθεί. Ωστόσο, ο επιχειρηματικός σας στόχος είναι να φέρετε ένα πλήρες προϊόν σε ένα πιάτο ακριβώς στην ώρα του ή ακόμη και πριν από την ώρα του. Τα πακέτα θα σας βοηθήσουν να εκπληρώσετε αυτά τα σχέδια, φέρνοντας npm ή νήματα στην κορυφή της λίστας των καλύτερων φίλων σας, αλλά να ξέρετε: κάθε λύση, όπως και αυτή, μπορεί επίσης να ενέχει κινδύνους. Και θα προσπαθήσουμε να τον περιγράψουμε και να σας δείξουμε έναν καλύτερο τρόπο για να τη γλιτώσετε στο παρακάτω άρθρο.
Ας ξεκινήσουμε με μια ιστορία...
Φανταστείτε ένα μεγάλο JavaScript έργο. Η επιχειρηματική απαίτηση υποχρεώνει τους προγραμματιστές να χρησιμοποιήσουν ένα συγκεκριμένο πακέτο, επιτρέποντας τη σωστή ενσωμάτωση με ένα άλλο σύστημα ενός πελάτη. Και αυτό είναι απολύτως εντάξει. MVP έχει φθάσει εγκαίρως, η επόμενη σύμβαση έχει υπογραφεί και η ανάπτυξη συνεχίζεται. Ο πελάτης ζητά να ενσωματώσει το επόμενο μέρος ενός συστήματος, το οποίο απαιτεί την ενημέρωση του πακέτου σας.
Αυτό το μέρος πηγαίνει καλά, μέχρι να γίνουν οι δοκιμές. Φαίνεται ότι το πακέτο περιέχει ένα απλό, αλλά ενοχλητικό σφάλμα, το οποίο δεν έχει ακόμη διορθωθεί σε καμία έκδοση του προϊόντος και είναι γνωστό ότι αυτό δεν θα συμβεί αρκετά σύντομα. Δεν μπορείτε απλά να διορθώσετε το node_modules κατάλογος - θα πρέπει να αφαιρεθεί από το αποθετήριο σας από την παρακολούθηση, επομένως οι συνεργάτες σας δεν θα μάθουν ποτέ τίποτα για τις αλλαγές σας! Λοιπόν, ενώ διαβάζατε αυτό το κείμενο, πιθανότατα έχετε ήδη καταλάβει τι πρέπει να κάνετε - fork. Αλλά χρειάζεστε πραγματικά ένα τέτοιο σφυρί;
Κατανοήστε το πρόβλημά σας
Πρέπει να γνωρίζετε αν το πρόβλημα που αντιμετωπίζετε αφορά μόνο εσάς ή μια ευρύτερη κοινότητα. Μερικές φορές, οι άνθρωποι ερμηνεύουν την έλλειψη συγκεκριμένης λειτουργικότητας ως σφάλμα, κάτι που δεν είναι πάντα σωστό. Ως εκ τούτου, η λύση σας μπορεί να μην γίνει αποδεκτή από μια κοινότητα και να μην συμπεριληφθεί σε ένα επίσημο αποθετήριο. Ωστόσο, εξακολουθείτε να το χρειάζεστε εδώ και τώρα. Λοιπόν, ας το επιδιορθώσουμε!
Σύμφωνα με τις σημειώσεις έκδοσης του αποθετηρίου github, το patch-package ) κυκλοφόρησε επίσημα τον Μάιο του 2017. It είναι ένα ισχυρό εργαλείο, το οποίο επιτρέπει τις τροποποιήσεις μέσα στο έργο εξάρτησης να εγκατασταθούν στο node_modules κατάλογος. Κάποιοι μπορεί να πουν ότι αυτό είναι μια τρέλα - πυροβολώντας εντολή εγκατάστασης ο διαχειριστής της εξάρτησής σας θα αντικαταστήσει τις αλλαγές.
Λοιπόν, αυτό είναι σωστό. Ωστόσο, ένα patch-package συνυπάρχει με npm και νήματα τέλεια (πρέπει να παραδεχτώ ότι λειτουργεί ελαφρώς καλύτερα με το npm μέχρι στιγμής, μπορείτε να διαβάσετε περισσότερα στην ενότητα "Why you should use postinstall-prepare with Yarn?" του αρχείου README) και εκμεταλλεύεται πλήρως την προετοιμασία ενός σεναρίου ("script": { "prepare":""}) του package.json αρχείο. Το patch-package δημιουργεί κυριολεκτικά έναν κατάλογο diff μεταξύ των αλλαγών σας και του αρχικού πακέτου, αποθηκευμένο στο φάκελο patch του τρέχοντος έργου σας..
Αφού εκτελέσει την εντολή install και κατεβάσει όλες τις εξαρτήσεις, εφαρμόζει αυτή τη διαφορά στον κατάλογο του έργου, κάνοντας μια τέλεια ανακατασκευή των αλλαγών σας για όλους τους συνεργάτες. Αυτό κάνει τη ζωή σας πιο απλή, έτσι δεν είναι; Η λύση αυτή έχει και κάποια μειονεκτήματα. Το patch-package δεν μπορεί να διορθώσει τις εξαρτήσεις του πακέτου σας ή να κάνει οποιεσδήποτε αλλαγές στο package.json.
Σε αυτή την περίπτωση μπορείτε να χρησιμοποιήσετε τη λύση με το πιρούνι. Επίσης, πρέπει να λάβετε υπόψη σας τον αριθμό των αλλαγών που πρόκειται να εφαρμόσετε στο πακέτο εξάρτησής σας και κατά πόσο θα αυξηθούν με την πάροδο του χρόνου. Σε περίπτωση που θα - θα πρέπει να σκεφτείτε προσεκτικά όταν χρησιμοποιείτε το fork, καθώς πρόκειται για ένα δικό σας έργο.
Μην είστε εγωιστές!
Το patching είναι ένας πολύ καλός τρόπος για να διορθώσετε τις εξαρτήσεις σας χωρίς να δημιουργείτε ατελείωτες διακλαδώσεις και να δημιουργείτε πολλαπλές πηγές έργου. Αλλά θα πρέπει πάντα να θυμάστε, ότι η αξιοποίηση της κοινότητας δεν πρέπει να είναι μονόδρομος. Αν βρείτε ένα σφάλμα ή νιώθετε ότι μπορείτε να βελτιώσετε το πακέτο που χρησιμοποιείτε, θα πρέπει πάντα να σκέφτεστε να βοηθήσετε τους άλλους, καταγράφοντας ένα ζήτημα ή ακόμα και συνεισφέροντας στο έργο!
