Campionatul JavaScript Full-Stack Bootcamp 2021 este ACUM DESCHIS PENTRU ÎNSCRIERI!

Ar trebui să trimiteți folderul node_modules în Git?

Am menționat Git, dar același lucru se aplică oricărui sistem de control al versiunilor pe care se întâmplă să îl folosiți

Este o întrebare bună de pus. Există argumente pro și contra.

Suger că valoarea implicită este de a nu comite folderul node_modules, și în schimb să-l adăugați la fișierul .gitignore.

Ați putea avea nevoi speciale care să inverseze această decizie.

Discut subiectul astfel încât să vă puteți face propria opinie.

Iată câteva argumente în favoarea ne-comiterii folderului node_modules

Vă păstrați istoricul Git curat. Când adăugați un nou pachet, stocați modificările de fișiere package.json și package-lock.json. când decideți să actualizați versiunea pachetului, tot ce stocați este modificarea de fișier package-lock.json.

package-lock.json este o caracteristică relativ nouă a npm, care înlocuiește comanda shrinkwrap folosită în trecut

Evitați să puneți posibil sute de MB de dependențe în depozitul dvs., iar acest lucru înseamnă că, în timp, va fi mai rapid să lucrați cu el. Schimbarea ramurilor și verificarea codului sunt 2 operații extrem de afectate de dimensiunea depozitului.

Când lucrați cu ramuri, s-ar putea să aveți conflicte de fuziune care se extind dincolo de codul dvs. și, în schimb, implică codul dependențelor. Acest lucru nu este plăcut de gestionat și vă poate face să pierdeți mult timp. Evitând să puneți

Un pull request sau o fuziune dacă se schimbă dependențele, va avea mult mai multe fișiere implicate în proces. Instrumentele devin mai lente sau chiar decid să nu afișeze dif complet (GitHub, de exemplu)

Modulele native node trebuie recompilate dacă implementați pe o platformă diferită de cea a mașinii dvs. de dezvoltare(caz de utilizare comun: dezvoltați pe Mac, implementați pe Linux). Trebuie să apelați npm rebuild, ceea ce scoate serverul din sincronizare.

Nu comiterea node_modules implică faptul că trebuie să vă listați toate modulele în package.json (și package-lock.json) ca un pas obligatoriu. Acest lucru este grozav pentru că s-ar putea să nu aveți sârguința de a face acest lucru, iar unele dintre operațiunile npm s-ar putea întrerupe dacă nu o faceți.

Tip: nu mai este nevoie să folosiți versiunea specifică în fișierul package.json, nu mai este nevoie de la introducerea fișierului package-lock.json.

Dacă folosiți seturi dependencies și devDependencies separate, prin confirmarea dosarului node_modules, practic confirmați devDependencies și nu există nicio modalitate (ușoară) pentru compilarea de producție de a scăpa de ele.

Motive care v-ar putea determina să confirmați node_modules și cum să le atenuați

Un pachet npm ar putea fi eliminat de către autorul său din registrul npm. S-a întâmplat cu faimosul incident left-pad din 2016 (citiți mai multe). Acest lucru este foarte rar să se întâmple pentru pachetele populare. Dacă se întâmplă acest lucru, s-ar putea să nu mai aveți acces la acea anumită parte de funcționalitate.

Ați putea argumenta, de asemenea, că npm nu este garantat să rămână pe termen nelimitat, ar putea dispărea, așa că o modalitate ușoară de a garanta că veți avea codul complet al aplicației dvs. în viitor este să îl trimiteți împreună cu aplicația dvs.

De fiecare dată când utilizați un pachet, creați un fork pe GitHub. Din când în când, mențineți-l la zi cu originea (poate fi automatizat).

Acest lucru nu este întotdeauna practic, deoarece pachetele pot avea zeci de dependențe proprii.

Puteți utiliza un server de depozit privat pentru proiectul dvs. și îl puteți folosi pentru a găzdui toate dependențele dvs.

Opțiunile includ

• sinopia
• npm_lazy
• npm-lazy-mirror
• artifactory
• npm Enterprise, de la compania npm

Un alt motiv pentru a confirma dependențele este posibilitatea de a edita rapid codul, dacă găsiți un bug sau dacă doriți să adăugați ceva la o bibliotecă.

Aceasta este o sabie cu două tăișuri: dacă faceți acest lucru, pierdeți posibilitatea de a actualiza pachetul în cazul în care se fac noi versiuni, iar acest lucru este bun doar pentru corecturi rapide și temporare.

Soluția optimă este fie să trimiteți un PR care să facă ceea ce doriți la proiectul original, fie să faceți un fork și să folosiți fork-ul dvs. ca dependență.

The 2021 JavaScript Full-Stack Bootcamp IS NOW OPEN FOR SIGNUPS UNUPS UNTIL NEXT TUESDAY! Nu ratați această oportunitate, înscrieți-vă AZI!

Mai multe tutoriale node:

• Cum să folosiți promisiuni și await cu funcțiile Node.js bazate pe callback
• The Node Core Modules
• Parsing JSON with Node.js
• Funcționarea cu descriptori de fișiere în Node
• Node.js Streams
• Cum să obțineți data ultimei actualizări a unui fișier folosind Node.js
• Ghidul Pug
• Obțineți folderul curent în Node
• Cum să utilizați REPL Node.js

.