paint-brush
Uau, pnpm, ești cu adevărat rapid: cum să-l folosești pe Herokude@alvinslee
174 lecturi

Uau, pnpm, ești cu adevărat rapid: cum să-l folosești pe Heroku

de Alvin Lee9m2024/11/09
Read on Terminal Reader

Prea lung; A citi

pnpm este o alternativă la npm și Yarn, un manager de pachete care gestionează diferit stocarea pachetelor, economisind spațiu utilizatorilor și reducând timpul de construire. Din mai 2024, pnpm este acum disponibil în Heroku. În această postare, vom acoperi ceea ce este nevoie pentru a începe cu pnpm pe Heroku și vom arăta unele dintre avantajele de stocare și de construire pe care le obțineți.
featured image -  Uau, pnpm, ești cu adevărat rapid: cum să-l folosești pe Heroku
Alvin Lee HackerNoon profile picture

Dacă sunteți un dezvoltator Node.js , atunci sunteți familiarizat cu npm și Yarn . S-ar putea chiar să aveți o părere puternică despre folosirea unuia față de celălalt. De ani de zile, dezvoltatorii se luptă cu umflarea - în stocarea pe disc și timpul de construire - atunci când lucrează cu managerii de pachete Node.js, în special cu npm .


Sursa: Reddit


Apoi, a apărut pnpm , un manager de pachete care gestionează stocarea pachetelor în mod diferit, economisind spațiu utilizatorilor și reducând timpul de construire. Iată cum descrie pnpm diferența :


„Când instalați un pachet, îl păstrăm într-un magazin global pe mașina dvs., apoi creăm un link hard din el în loc să îl copiem. Pentru fiecare versiune a unui modul, există o singură copie păstrată pe disc. Când utilizați npm sau yarn, de exemplu, dacă aveți 100 de pachete folosind lodash, veți avea 100 de copii de lodash pe disc. pnpm vă permite să economisiți gigaocteți de spațiu pe disc!”


Nu este surprinzător faptul că pnpm câștigă teren, din ce în ce mai mulți dezvoltatori făcându-l managerul de pachete ales. Odată cu această rată de adoptare în creștere, mulți dezvoltatori care își rulează aplicațiile pe Heroku (ca și mine) au vrut să vadă pnpm acceptat.


Din fericire, pnpm este disponibil prin Corepack , care este distribuit cu Node.js. Deci, din mai 2024, pnpm este acum disponibil în Heroku !

În această postare, vom acoperi ceea ce este nevoie pentru a începe cu pnpm pe Heroku. Și, de asemenea, vom evidenția unele dintre beneficiile de stocare și timp de construcție pe care le obțineți în urma utilizării acestuia.

Un instructaj rapid despre pnpm

pnpm a fost creat pentru a rezolva problema de lungă durată a managerului de pachete Node.js a stocării redundante și a ineficiențelor în gestionarea dependențelor . npm și Yarn copiați dependențele în node_modules ale fiecărui proiect. În schimb, pnpm păstrează toate pachetele pentru toate proiectele într-un singur magazin global și apoi creează link-uri hard către aceste pachete, în loc să le copieze. Ce înseamnă acest lucru?


Să presupunem că avem un proiect Node.js care utilizează lodash . Desigur, proiectul va avea un folder node_modules , împreună cu un subfolder numit lodash , plin cu fișiere. Mai exact, [email protected] are 639 de fișiere și un alt subfolder numit fp , cu alte 415 fișiere.


Adică peste o mie de fișiere numai pentru lodash !


Am creat șase proiecte Node.js: două cu pnpm, două cu npm și două cu Yarn. Fiecare dintre ele folosește lodash . Să aruncăm o privire la informațiile doar pentru unul dintre fișierele din folderul de dependență lodash .


 ~/six-projects$ ls -i npm-foo/node_modules/lodash/lodash.js 14754214 -rw-rw-r-- 544098 npm-foo/node_modules/lodash/lodash.js ~/six-projects$ ls -i npm-bar/node_modules/lodash/lodash.js 14757384 -rw-rw-r-- 544098 npm-bar/node_modules/lodash/lodash.js ~/six-projects$ ls -i yarn-foo/node_modules/lodash/lodash.js 14760047 -rw-r--r-- 544098 yarn-foo/node_modules/lodash/lodash.js ~/six-projects$ ls -i yarn-bar/node_modules/lodash/lodash.js 14762739 -rw-r--r-- 544098 yarn-bar/node_modules/lodash/lodash.js ~/six-projects$ ls -i pnpm-foo/node_modules/lodash/lodash.js 15922696 -rw-rw-r-- 544098 pnpm-foo/node_modules/lodash/lodash.js ~/six-projects$ ls -i pnpm-bar/node_modules/lodash/lodash.js 15922696 -rw-rw-r-- 544098 pnpm-bar/node_modules/lodash/lodash.js


Fișierul lodash.js are o dimensiune de puțin peste jumătate de megaoctet. Nu vedem linkuri soft, așa că, la prima vedere, se pare că fiecare proiect are propria sa copie a acestui fișier. Cu toate acestea, nu este chiar așa.


Am folosit ls cu steag-ul -i pentru a afișa inodul fișierului lodash.js . Puteți vedea în proiectele pnpm-foo și pnpm-bar , ambele fișiere au același inod ( 15922696 ). Ei indică același fișier! Acesta nu este cazul pentru npm sau Yarn.


Deci, dacă aveți o duzină de proiecte care folosesc npm sau Yarn și acele proiecte folosesc lodash , atunci veți avea o duzină de copii diferite ale lodash , împreună cu copii din alte dependențe în acele proiecte care folosesc ele însele lodash . În pnpm, fiecare proiect și dependență care necesită această versiune specifică de lodash indică aceeași copie globală unică.


Codul pentru [email protected] are o dimensiune de puțin sub 5 MB. Ați prefera să aveți 100 de copii redundante ale acestuia pe computer sau doar o copie globală?


La sfârșitul zilei, instalarea dependenței cu pnpm este semnificativ mai rapidă, necesitând mai puțin spațiu pe disc și mai puține resurse. Pentru dezvoltatorii care lucrează în mai multe proiecte sau care gestionează dependențe pe platformele cloud, pnpm oferă o modalitate mai simplă și mai rapidă de a gestiona pachetele. Acest lucru face ca pnpm să fie ideal pentru un mediu de implementare simplificat precum Heroku.


Ești gata să începi să-l folosești? Să vedem cum.

Noțiuni introductive cu pnpm

Iată versiunea de Node.js cu care lucrăm pe mașina noastră:


 $ node --version v20.18.0

Activați și utilizați pnpm

După cum am menționat mai sus, Corepack vine cu Node.js, așa că trebuie pur și simplu să folosim corepack pentru a activa și folosi pnpm. Creăm un folder pentru proiectul nostru. Apoi, rulăm aceste comenzi:


 ~/project-pnpm$ corepack enable pnpm ~/project-pnpm$ corepack use pnpm@latest Installing [email protected] in the project... Already up to date Done in 494ms


Aceasta generează un fișier package.json care arată astfel:


 { "packageManager": "[email protected]+sha512.22721b3a11f81661ae1ec68ce1a7b879425a1ca5b991c975b074ac220b187ce56c708fe5db69f4c962c989452eee76c82877f4ee80f474cebd61ee13461b6228" }


Acest lucru generează și un fișier pnpm-lock.yaml .


Apoi, adăugăm dependențe la proiectul nostru. În scopuri demonstrative, copiem lista de dependencies și devDependencies găsite în acest fișier de evaluare comparativă package.json pe GitHub . Acum, fișierul nostru package.json arată astfel:


 { "version": "0.0.1", "dependencies": { "animate.less": "^2.2.0", "autoprefixer": "^10.4.17", "babel-core": "^6.26.3", "babel-eslint": "^10.1.0", ... "webpack-split-by-path": "^2.0.0", "whatwg-fetch": "^3.6.20" }, "devDependencies": { "nan-as": "^1.6.1" }, "packageManager": "[email protected]+sha512.22721b3a11f81661ae1ec68ce1a7b879425a1ca5b991c975b074ac220b187ce56c708fe5db69f4c962c989452eee76c82877f4ee80f474cebd61ee13461b6228" }


Apoi, instalăm pachetele.


 ~/project-pnpm$ pnpm install

Compararea comenzilor comune

Utilizarea pentru pnpm este destul de asemănătoare cu npm sau cu fire și, prin urmare, ar trebui să fie intuitivă. Mai jos este un tabel care compară diferitele utilizări pentru comenzile comune (preluate din această postare ).


Comparația vitezei de construcție Heroku

Acum că am arătat cum să punem în funcțiune un proiect cu pnpm (este destul de simplu, nu?), am vrut să comparăm timpii de construire pentru diferiți manageri de pachete atunci când rulăm pe Heroku. Am configurat trei proiecte cu dependențe identice - folosind npm, Yarn și pnpm.


În primul rând, ne conectăm la Heroku CLI ( heroku login ).


Apoi, creăm o aplicație pentru un proiect. Vom arăta pașii pentru proiectul npm.


 ~/project-npm$ heroku apps:create --stack heroku-24 npm-timing Creating ⬢ npm-timing... done, stack is heroku-24 https://npm-timing-5d4e30a1c656.herokuapp.com/ | https://git.heroku.com/npm-timing.git


Am găsit un pachet de construcție care adaugă marcaje temporale la pașii de construire în jurnalul Heroku, astfel încât să putem calcula timpii de construcție efectivi pentru proiectele noastre. Dorim să adăugăm acel pachet de compilare la proiectul nostru și să îl rulăm înaintea pachetului de compilare standard pentru Node.js. Facem asta cu următoarele două comenzi:


 ~/project-npm$ heroku buildpacks:add \ --index=1 \ https://github.com/edmorley/heroku-buildpack-timestamps.git \ --app pnpm-timing ~/project-npm$ heroku buildpacks:add \ --index=2 heroku/nodejs \ --app npm-timing Buildpack added. Next release on npm-timing will use: 1. https://github.com/edmorley/heroku-buildpack-timestamps.git 2. heroku/nodejs Run git push heroku main to create a new release using these buildpacks.


Asta este! Apoi, ridicăm codul pentru proiectul nostru gestionat de npm.


 ~/project-npm$ git push heroku main ... remote: Updated 4 paths from 5af8e67 remote: Compressing source files... done. remote: Building source: remote: remote: -----> Building on the Heroku-24 stack remote: -----> Using buildpacks: remote: 1. https://github.com/edmorley/heroku-buildpack-timestamps.git remote: 2. heroku/nodejs remote: -----> Timestamp app detected remote: -----> Node.js app detected ... remote: 2024-10-22 22:31:29 -----> Installing dependencies remote: 2024-10-22 22:31:29 Installing node modules remote: 2024-10-22 22:31:41 remote: 2024-10-22 22:31:41 added 1435 packages, and audited 1436 packages in 11s remote: 2024-10-22 22:31:41 remote: 2024-10-22 22:31:41 184 packages are looking for funding remote: 2024-10-22 22:31:41 run `npm fund` for details remote: 2024-10-22 22:31:41 remote: 2024-10-22 22:31:41 96 vulnerabilities (1 low, 38 moderate, 21 high, 36 critical) remote: 2024-10-22 22:31:41 remote: 2024-10-22 22:31:41 To address issues that do not require attention, run: remote: 2024-10-22 22:31:41 npm audit fix remote: 2024-10-22 22:31:41 remote: 2024-10-22 22:31:41 To address all issues possible (including breaking changes), run: remote: 2024-10-22 22:31:41 npm audit fix --force remote: 2024-10-22 22:31:41 remote: 2024-10-22 22:31:41 Some issues need review, and may require choosing remote: 2024-10-22 22:31:41 a different dependency. remote: 2024-10-22 22:31:41 remote: 2024-10-22 22:31:41 Run `npm audit` for details. remote: 2024-10-22 22:31:41 npm notice remote: 2024-10-22 22:31:41 npm notice New minor version of npm available! 10.8.2 -> 10.9.0 remote: 2024-10-22 22:31:41 npm notice Changelog: https://github.com/npm/cli/releases/tag/v10.9.0 remote: 2024-10-22 22:31:41 npm notice To update run: npm install -g [email protected] remote: 2024-10-22 22:31:41 npm notice remote: 2024-10-22 22:31:41 remote: 2024-10-22 22:31:41 -----> Build remote: 2024-10-22 22:31:41 remote: 2024-10-22 22:31:41 -----> Caching build remote: 2024-10-22 22:31:41 - npm cache remote: 2024-10-22 22:31:41 remote: 2024-10-22 22:31:41 -----> Pruning devDependencies remote: 2024-10-22 22:31:44 remote: 2024-10-22 22:31:44 up to date, audited 1435 packages in 4s remote: 2024-10-22 22:31:44 remote: 2024-10-22 22:31:44 184 packages are looking for funding remote: 2024-10-22 22:31:44 run `npm fund` for details remote: 2024-10-22 22:31:45 remote: 2024-10-22 22:31:45 96 vulnerabilities (1 low, 38 moderate, 21 high, 36 critical) remote: 2024-10-22 22:31:45 remote: 2024-10-22 22:31:45 To address issues that do not require attention, run: remote: 2024-10-22 22:31:45 npm audit fix remote: 2024-10-22 22:31:45 remote: 2024-10-22 22:31:45 To address all issues possible (including breaking changes), run: remote: 2024-10-22 22:31:45 npm audit fix --force remote: 2024-10-22 22:31:45 remote: 2024-10-22 22:31:45 Some issues need review, and may require choosing remote: 2024-10-22 22:31:45 a different dependency. remote: 2024-10-22 22:31:45 remote: 2024-10-22 22:31:45 Run `npm audit` for details. remote: 2024-10-22 22:31:45 npm notice remote: 2024-10-22 22:31:45 npm notice New minor version of npm available! 10.8.2 -> 10.9.0 remote: 2024-10-22 22:31:45 npm notice Changelog: https://github.com/npm/cli/releases/tag/v10.9.0 remote: 2024-10-22 22:31:45 npm notice To update run: npm install -g [email protected] remote: 2024-10-22 22:31:45 npm notice remote: 2024-10-22 22:31:45 remote: 2024-10-22 22:31:45 -----> Build succeeded! ...


Ne-am uitat la momentul următorilor pași, până când mesajul Build succeeded aproape de sfârșit:

  • Installing dependencies
  • Build
  • Pruning devDependencies
  • Caching build


În total, cu npm, această construcție a durat 16 secunde.


Am rulat aceeași configurare pentru proiectul gestionat de pnpm, folosind și pachetul de compilare timings.


 ~/project-pnpm$ heroku apps:create --stack heroku-24 pnpm-timing ~/project-pnpm$ heroku buildpacks:add \ --index=1 \ https://github.com/edmorley/heroku-buildpack-timestamps.git \ --app pnpm-timing ~/project-pnpm$ heroku buildpacks:add \ --index=2 heroku/nodejs \ --app pnpm-timing ~/project-pnpm$ git push heroku main … remote: 2024-10-22 22:38:34 -----> Installing dependencies remote: 2024-10-22 22:38:34 Running 'pnpm install' with pnpm-lock.yaml … remote: 2024-10-22 22:38:49 remote: 2024-10-22 22:38:49 dependencies: remote: 2024-10-22 22:38:49 + animate.less 2.2.0 remote: 2024-10-22 22:38:49 + autoprefixer 10.4.20 remote: 2024-10-22 22:38:49 + babel-core 6.26.3 … remote: 2024-10-22 22:38:51 -----> Build succeeded!


Pentru aceeași versiune cu pnpm, a durat doar 7 secunde.


Am descoperit că economiile de timp nu se referă doar la instalarea inițială. Compilările ulterioare, care folosesc cache-ul de dependență, sunt, de asemenea, mai rapide cu pnpm.


Concluzie

Când am început dezvoltarea Node.js , am folosit npm. Cu câțiva ani în urmă, am trecut la Yarn și asta am folosit. . . până de curând. Acum, am trecut la pnpm. Pe computerul meu local, pot elibera spațiu substanțial pe disc. Construcțiile sunt și mai rapide. Și acum, cu suport Heroku pentru pnpm, acest lucru închide bucla, astfel încât să îl pot folosi exclusiv de la dezvoltarea locală până la implementarea în cloud.


Codare fericită!