de Jacob Worrel

Ce să vă întrebați înainte de a adăuga un pachet NPM la proiectul dvs.

Ce sa va intrebati inainte de a adauga un pachet
Credit de imagine Andreas Gursky, Amazon, 2016

Unul dintre cele mai mari lucruri despre a fi dezvoltator JavaScript astăzi este abilitatea de a valorifica ecosistemul său incredibil de bogat. Cu aproape un milion pachetele din registrul NPM, nu este neobișnuit să se ajungă la o soluție disponibilă atunci când se confruntă cu o problemă rezolvată frecvent. Cu cât petreceți mai puțin timp reinventând roata, cu atât vă puteți concentra mai mult asupra problemei mai mari la îndemână.

Acestea fiind spuse, nu toate sursele deschise sunt create egale și este probabil o idee bună să vă faceți temele înainte de a face saltul și în funcție de codul altcuiva. Iată câteva întrebări de bază pe care ar trebui să le puneți înainte de a adăuga un nou pachet NPM la proiectul dvs. și instrumentele pe care le puteți folosi pentru a le răspunde.

TL; DR

Următoarele întrebări se bazează pe experiența mea ca dezvoltator JavaScript și nu sunt în niciun caz exhaustive. Dacă credeți că lipsește ceva, vă rugăm să nu ezitați să mă anunțați în comentarii!

Cât de popular este? Uită-te la descărcările săptămânale pe NPM și stele pe Github.

Cât de matur este? Uitați-vă la data primei versiuni publicate pe NPM și la numărul de numere deschise față de cele închise de pe Github.

Se menține activ? Uită-te la istoricul de comitere și la Angajamente și Frecvența codului diagrame (sub fila Insights) de pe Github. Verificați data „ultimei publicări” pe NPM.

Cât de mare este? Verificați dimensiunea pachetului Bundlefobie.

Are acoperire de testare? Verificați dacă există ecusoane de acoperire pe NPM / Github. Deschideți fișierele de testare.

Ce sa va intrebati inainte de a adauga un pachet
Popularitatea bibliotecilor CSS-in-JS prin descărcări NPM, prin amabilitatea npmcharts.

Popularitatea este probabil primul lucru pe care majoritatea oamenilor doresc să îl știe atunci când caută un pachet open source pentru a-și rezolva problema – mai precis, câte stele are pe Github și câte descărcări săptămânale obține pe NPM.

Și, deși aceste două valori ar putea să vă dea un impuls cu privire la cât de multă tracțiune are un proiect în cadrul comunității, cu siguranță ar trebui să luați aceste numere cu un bob de sare. Rețineți că o stea Github este practic echivalentul unui „like” de pe site-urile de socializare și că mulți dezvoltatori le vor arunca ca bomboane. Eu sunt vinovat de acest lucru și faptul că am jucat o repo nu înseamnă că am verificat calitatea codului și i-am dat aprobarea completă.

Când vine vorba de descărcări, chiar și NPM admite că statisticile lor sunt „naiv prin design”Deoarece includ descărcări de servere automate de construire, oglinzi și roboți. Totuși, trebuie să începeți de undeva, astfel încât s-ar putea la fel de bine să eliminați această întrebare. Rețineți că acesta este probabil cel mai puțin important (și adesea cel mai înșelător!) Factor, așa că asigurați-vă că faceți diligența și cu siguranță nu vă opriți aici.

Cât de matur este?

1611314408 374 Ce sa va intrebati inainte de a adauga un pachet
Un număr sănătos de probleme deschise față de cele închise este un bun indicator al cât de matur este un proiect.

Dacă ai auzit de Regula 80/20, probabil că sunteți familiarizat cu conceptul că primele 80% din cod se realizează de obicei în 20% din timp, iar restul de 20% le ia pe celelalte 80% din timp. Acest lucru se datorează faptului că este de obicei ușor să puneți în funcțiune ceva, dar gestionarea tuturor cazurilor marginale, remedierea erorilor neprevăzute și gestionarea performanței și a scării este adesea cea mai provocatoare parte a scrierii unui software stabil. Acesta este motivul pentru care în mod ideal doriți să utilizați doar sursa deschisă care a fost testată în luptă și a rezistat testului timpului.

Primul lucru de verificat este când a fost publicat pentru prima dată un pachet. Accesați pagina NPM a proiectului, faceți clic pe fila Versiuni pentru a obține istoricul complet al fiecărei versiuni și derulați până în jos. O istorie lungă, cu multe lansări, este de obicei un semn bun, deoarece înseamnă că proiectul a fost repetat în timp.

Următorul și probabil cel mai bun indicator al unui proiect matur este numărul de probleme deschise și închise de pe Github. De obicei, este o idee bună să privim aceste două numere împreună, deoarece unul nu înseamnă cu adevărat atât de mult fără celălalt. Un număr mare de probleme deschise nu este neapărat un lucru rău dacă numărul de probleme închise este chiar mai mare. Pentru a vă oferi un cadru de referință, începând cu această scriere, Reacţiona are aproximativ 400 de numere deschise, dar mai mult de 6500 închise. Node.js are aproximativ 600 de numere deschise și aproape 9000 închise.

Nu există un raport magic, dar ferește-te de orice proiect cu un număr mare de probleme deschise în raport cu câte probleme au fost închise. Pe de altă parte, un număr redus de probleme deschise nu este neapărat un lucru bun dacă și numărul de probleme închise este mic. Acest lucru înseamnă probabil că nu a fost folosit prea mult și se află încă într-un stadiu incipient de dezvoltare.

Se menține activ?

1611314408 893 Ce sa va intrebati inainte de a adauga un pachet
Fila Statistici de pe Github

Cu excepția cazului în care un proiect este deja foarte matur și nu adaugă caracteristici noi sau nu face ceva relativ mic, este important să fie întreținut în mod activ. Vă amintiți regula 80/20? Singurul mod în care software-ul trece de la nou și experimental la stabil și matur este prin întreținerea activă, ceea ce înseamnă remedierea regulată a erorilor și îmbunătățiri suplimentare.

Din experiența mea, cel mai bun mod de a verifica acest lucru este uitându-vă la istoricul de comitere din ramura principală a proiectului. Mai întâi, faceți clic pe numărul de confirmări de pe pagina Github a proiectului și verificați când ultima comitere a fost îmbinată cu master. Această dată nu înseamnă foarte mult de la sine, ci este o parte importantă a imaginii de ansamblu.

Dacă sunteți ca mine și preferați să vedeți acest tip de date vizualizate, faceți clic pe fila Insights, unde puteți culege tot felul de informații despre repo. Aș putea scrie, probabil, o întreagă postare de blog despre această caracteristică, așa că tot ce voi spune este că, dacă nu ați folosit încă acest lucru, nu mai citiți, accesați pagina Github a proiectului dvs. open source preferat și începeți să vă jucați cu ea .

Îmi place în mod deosebit Angajamente și Frecvența codului graficele, deoarece îmi spun dintr-o privire cât de mult se lucrează la proiect. Amintiți-vă, totuși, doar pentru că nu există o mulțime de confirmări recente nu înseamnă că codul nu poate fi de încredere. Dimpotrivă, acesta este uneori un semn de maturitate – în captura de ecran de mai sus, diagrama de frecvență a codului pentru Express este o vizualizare excelentă pentru cum arată un proiect matur.

Nu în ultimul rând, mi se pare util să știu când a fost publicată ultima dată o nouă versiune pe NPM, care este inclusă în statisticile eroilor de pe pagina NPM a unui proiect. Acest lucru îmi dă o idee generală cu privire la frecvența cu care mentenanții programează de fapt lansări, comparativ doar cu comiterea codului.

Cât de mare este?

1611314408 531 Ce sa va intrebati inainte de a adauga un pachet
O defalcare a modulului NPM d3 activat Bundlefobie.

Nimănui nu-i place un pachet umflat. Și, deși este ușor să adăugați în continuare module nod la un proiect, acest lucru poate veni la un cost. Minimizarea, compresia și împărțirea codului ajută foarte mult, dar la sfârșitul zilei, totul se reduce la cât de mult JavaScript trimiteți clientului.

Merg la resursa pentru asta Bundlefobie, un site minunat care nu numai că vă arată dimensiunea pachetului unui pachet NPM, ci tot felul de alte lucruri fanteziste. În imaginea de mai sus, puteți vedea timpul estimat de descărcare pe rețele lente, evoluția dimensiunii pachetului pe parcursul diferitelor versiuni și compoziția dependențelor. De asemenea, vă va spune dacă pachetul este optimizat pentru a valorifica arborele cu agregatori moderni, cum ar fi Webpack, și chiar sugerează module similare, cu statistici care compară modul în care acestea se acumulează în funcție de dimensiuni!

În mod ideal, doriți să utilizați module cu o dimensiune mică și un număr redus de dependențe, dacă există. Desigur, dimensiunea este relativă, deci asigurați-vă că comparați merele cu merele – dacă vă uitați la o bibliotecă de graficare, de exemplu, asigurați-vă că o comparați cu alte biblioteci de graficare (care tind să fie la capătul mai mare a spectrului).

Are acoperire de testare?

1611314408 271 Ce sa va intrebati inainte de a adauga un pachet
O bibliotecă de testare fără acoperire de testare …?

Acest lucru poate părea evident, dar întotdeauna, întotdeauna, verifică întotdeauna acoperirea testelor. Codul în care nu poți testa este cod în care nu poți avea încredere.

În zilele noastre, este mult mai ușor să obțineți o imagine de nivel înalt a acoperirii datorită unor instrumente precum Salopete și Codecov– care urmăresc acoperirea în timp și oferă autorilor insigne strălucitoare pe care le pot afișa cu mândrie pe paginile lor Github și NPM. Rețineți însă că instrumentele de acoperire a testelor verifică doar cât de mult cod este executat în timpul testelor și poate fi derutant câteodată. Dacă doriți cu adevărat să intrați în nitty-gritty, nu există nici un substitut pentru deschiderea fișierelor de testare și citirea specificațiilor de testare.

Și, desigur…

Urmează versiunile semantice?

Versiunea semantică este o modalitate prin care autorii open source pot comunica – prin numărul versiunii – cu consumatorii software-ului lor despre ce fel de modificări include o nouă versiune. Vă asigură că știți când sunt introduse modificări de rupere și, prin urmare, rămâneți în controlul codului dvs., în ciuda dependenței de alte module. Mai multe despre versiuni semantice aici.

Care este licența?

Dacă ai fi în jur pe tot parcursul Reacționați dezastrul licenței, probabil că ați aflat că este o idee bună să verificați licența înainte de a începe să utilizați orice software open source, ca nu cumva o organizație aparent binevoitoare să încerce să vă atragă una rapidă. Le puteți găsi în codul sursă, de obicei în directorul rădăcină al proiectului. Căutați licențe permisive precum Licență MIT, care practic vă permite să faceți orice doriți, cu excepția acțiunii în judecată a autorului. Mai multe despre licențe aici.

Așa este, citește codul sursă!

În timp ce întrebările discutate mai sus sunt o modalitate bună de a arunca o privire asupra stării generale a unui pachet NPM, cel mai bun mod de a determina calitatea codului pentru orice proiect este aruncând o privire asupra codului sursă. Desigur, acest lucru durează mult mai mult decât parcurgerea paginilor NPM / Github / Bundlephobia ale unui proiect, așa că este puțin probabil să faceți acest lucru pentru fiecare dependență. Cu toate acestea, probabil că va da roade dacă modulul este esențial pentru aplicația dvs. S-ar putea chiar să vă salvați de o durere de cap majoră mai târziu, dacă descoperiți o întrerupere a tranzacțiilor care altfel ar fi putut trece neobservată.

Notă cu privire la componentele de interfață terță parte

Dacă utilizați un cadru front-end bazat pe componente, cum ar fi React, Vue sau Angular, este posibil să aveți în componența dvs. o componentă UI terță parte package.json dependențe. Și, deși toate întrebările ridicate în acest post încă se aplică, componentele UI necesită o examinare suplimentară, pe care intenționez să o abordez într-o postare viitoare, așa că stați la curent!