Перакіранне праекту Node з npm на pnpm без парадоксаў для каманды

Манеджэры пакетаў адлучваюць, як залежнасці будуць захаваны на дыске, які файл блакавання запісваць, і насколькі строгіяе будзе прыйманне новых пакетаў, калі выйдзе проблема. Для багато праектаў на Node стандартным выборам застаецца npm. Команды, якія адпаведзяюць за калькі рэпазітарыяў, таксама сталквуюцца з постаямым прыпłyвам паведамленняў пра безпеку, якія прасябае падняць версію. Dependabot можа автаматычна адкрываць дзеяныя з гэтых апдэйтаў; іншыя апгрэйды трэбуе ручной працы, таму што перадачныя патчы ствараюць суперсечанні, або таму што ефектыўным рашэнням ёсць цэлычна заменіць пакет.

Прыблізна ў тым жа перыядзе GitHub скоракаў Dependabot так, што PR-ы на падняць версію, якія не стосуюцца безпекі, чакаюць тры дні прыбліжна, перш чым будуць адкрываны. Гэя змена правіл больш заўсёды не стосуецца выбору манеджэра пакетаў, але яна паказвае, насколькі гучнымі сталі автаматычныя апгрэйды.

Тым часам інцыдэнты ў ланцугу саплывоў продавяліваюцца ў загалоўныя статыі. Паставленыя пад атаку чы сусветлівыя пакеты знаходзяцца ўнутры прыкладнікаў, якія запошчаюць наборы іконак, адміністрацыйныя калькуляторы і іншы інструменты, таму радыяус уражэння расшыроўваецца з кожным пераходам. Апавешчэнняя пра абяцанні безпекі рэдка калі прыходзяць по аднаму. Ноутбук, які клонуе калькуючыяся службы, за той жа тыдзень павінен пабачыць апавешчэнняя пра пераходныя парсеры, наборы інтэрфейсу і адміністрацыйныя мідлвэры. Аўтаматычныя боты дапамагаюць, калі проблема механічная; яны страждаюць, калі новая версія перапішае API-і чы колі два залежнасці не пагоджуюцца ў спяльнам партнеры. У такія тыдзены цікава запытацца, чы можа сам інсталляр зменшыць рызык — адмовіўшыся ад фантамных залежнасцяў, раздзеліўшы кантэнт на дыску, южаб працягвання новых публікацый, пакуль экасістэма не пераглядзіць сітуацыю.

Адзін з часта практыкуемых падакоў — заменіць npm на pnpm: схожыя кождадзённыя команды, стрэльнейшы мадэль інсталяціі і зазвычай меншая навантажэнна на дыск. У наступных раздзелах практыкуецца параваненне гэтых двух інструментоў без прызначэння абсалютнага пераможця — толькі столькі дакладнасці, каб можна было выявіць, чы рэальна пераход на іншы інструмент зарады зменшэння віткоў на міграцыю.

Абшчая інфармацыя пра npm / pnpm

Короткая аснова для кожнага інструмента:

npm

• Ўжо ўключаецца як стандартны менеджэр пакетаў у Node.js.
• Контролюе інсталяцыю залежнасцяў і скрыпты package.json.
• Кождадзённыя команды включаюць npm install (інсталяцыя з файлу lock/manifest), npm install <name> (дадаць залежнасць), npm run <script> і npm uninstall <name>.
• Стварае файл package-lock.json.
• Зберагае пакеты ў катэгорыі node_modules.

npm таксама выдае npx, які запускае пакет без яго дадзення ў праект чы аб’явлення яго глобальна. Інструменты для стварэння каркаса, такія як npx create-vite@latest project-name, врэменна завантажваюцься, запускаюцца і не паўтараюць змянення ў package.json. Разлік з npm install ёсць намеровым: одноразовы запуск протыраць стойкай залежнасці.

pnpm

• Менеджэр пакетаў трэцьяго сторонньага выдавальніка, які выпаловае тыя ж задачы — залежнасці і скрыпты — але іншым спосабам на дыску.
• Звычныя каманды маюць сэроднія назвы: pnpm install, pnpm add <name>, pnpm run <script>, pnpm remove <name>.
• Зазвычай ён выкарыстоўвае менш прастору на дыску і шырэй за час завершае інсталляцію, так як кожную версію зберагае толькі раз.
• Обмежвае імпорты тым, што зазначае package.json.

Ўзаець pnpm-lock.yaml замест package-lock.json.

Застаўляе стрэжэйшыя стандартныя настройкі для недавна апублікованых версый (напрыклад, затрымляе ўжыццё).

Раннер, падобны npx, — гэта pnpm dlx; ён корыстны, напрыклад, пад час стварэння праекта з create-vite. Багато генератораў таксама падтрымліваюць pnpm create. Для бінарных файлаў, якія ўжо знаходзяцца ў node_modules, як местны раннер выступае pnpm exec.

Працоўныя і недзеянкі pnpm

Компрэсіі маюць такое ж значэнне, як і слоганы:

• npm копіюе пакеты ў node_modules кожнага праекту, чым ствараюцца дублікаты ў розных рэпазітарыях; pnpm зберагае адну копію на кожную версію, якая можа быць адсылаемая па адрэсе, і стварае звязкі з праектамі.
• Такая структура зазвычай зменшвае выкарыстоўванне дыска і прыбліжае час павтарных інсталляцый.
• Завдзяк таму, што npm історычна ўсё больш простае у рашэнаванні, код можа выкарыстоўваць пакет, які ніколі не быў адзначаны; pnpm адмовляецца прыймаць неадзначаныя імпорты, чыгуча зменшаючы плошчу для вялікіх атак.
• Запазджанне pnpm у застосоўванні аблікованых наватна новыя версіі зменшае шансы на тое, што будзе атрымана заражаная версія пакета.
• З часам npm таксама атрымала супарадныя можлівасці, але калькі з іх застаюцца нестандартнымі, а не стандартнымі.
• pnpm выклекае аддзельны крок інсталляцыі; npm ўжо ўключаецца разам з Node.
• Старэйшыя плагіны, якія вырачоўваюць структуру npm, можа патрабаваць змян пад стрэжчымі правіламі супалювання пакетаў у pnpm.
• Командная прычыпленасць да npm застаецца вялікай, таму практычнае адкалічэнне на pnpm можа зайняць калькі часу.

Разлікі ў распаковцы дыска быстра стаюць пометнымі на серверах CI, які пагана кэшуе node_modules, а таксама на камп’ютарах распрацоўшчыкаў, дзе запускаецца дзесяткі прыемоў. Зберагач з адрэсаваннем кантэнту значыць, што другія і трохія праекты, якім патрэбны lodash@4.x, здэбольшай ствараюць лінкі заместо ўсё новага дрэва структуры. Адносна строгей візуабельнасць залежнасцяў таксама вплывае на адлагоджванне: калі імпорт не выходзіць таму, што пакет ніколі не быў заявлены, проблема стае пометной ў момент інсталляцыі чы адпаведнага пераканальвання, а не ў момент выканання, калі прыемка відбываецца толькі таму, што іншы пакет яго ўзяў.

Пераход на pnpm

Мінімальная глобальная інсталляцыя выглядае так:

// Installation command (once)
npm install -g pnpm

// Usage
pnpm install
pnpm add [package name]
pnpm run [script name]
pnpm remove [package name]

Пасля першай успешнай інсталляцыі ў праекце, магчыма, з’явіцца файл pnpm-lock.yaml падле (а згодзе і заместо) package-lock.json.

Існуюць іншыя спосабы інсталяціі, укладаючы самастоятныя скрыпты; інструкцыі з інсталяціі pnpm пераказваюць іх.

Міграцыя вялікага праекту npm зазвычай значыць выдаленне файлаў node_modules і package-lock.json, а пасля — запуск команды pnpm install. Большасць дапрацоўак запускаецца без проблем; аднак некалькі натыўных дадаткаў або застарэлых рашэйвераў можа патрабаваць спецыяльных правак.

Ёсць можласць запісаць версіі з існуючага файла lockfile за дапамою команды pnpm import. Чыставаць залішкі npm можна так:

// For macOS/Linux/Git Bash:
rm -rf node_modules package-lock.json

// For Windows PowerShell:
rm -Recurse -Force node_modules, package-lock.json

Ёсць спосаб запобачыць случайны запуск npm install пазней — трэба дадаць функцыю preinstall:

"scripts": {
  "preinstall": "npx only-allow pnpm"
}

Пасля чаго дапаможны кантэнт можна дадаць як залежнасць для разработкі:

pnpm add -D only-allow

Для фіксацыі точнай версіі CLI для саавтароў вікорыстоўваецца палец packageManager (версію можна зменіць за патрэбам):

{
  "packageManager": "pnpm@11.22.0"
}

Этот пін прымечвае CI і ноутбукі да адной версіі CLI; не забудзьце яшчэ раз падняць яго, калі команда апгрэйдавае ўстаткуванне.

Працюйце з ім і самастаўляйце версію за дапамою:

pnpm --version

pnpm self-update

Калі самастаўленне версіі не працуе належна, перынсталюйце пакет глобальна за дапамою npm install -g pnpm і пачніце працу шэлу занова.

Пасля успешнага перыявлення вы должны бачыць:

• package-lock.json не існуе.
• pnpm-lock.yaml ўсё ж існуе.
• package.json застаецца незменным, за выключэнням пінаў чы сцраптов, якія вы дадалі.
• node_modules перапісваецца пад час работы лінкера pnpm (альбо ствараецца занова праз pnpm install).
• Команды для ўседзённай працы, якія пераважна разлічаюцца толькі назвай інструмента ў пачатку.
• Одноразовыя запускічы за дапамою pnpm dlx там, дзе раней вы вжывалі npx.

Афіцыйная дакументацыя застаецца месцам для раследавання спецыяльных кейсаў; вышэйзгаданыя прыміткі дастатковы, каб ацэніць працэс міграцыі і адбыць стандартную замену.

Спрытывайце першы мігруйны рэпазітарый як рэпетыцыю: запускайце набор тэстаў, пераканаюцеся, што складанні з Docker усё ўсунулі проблемы, і пераканаюцеся, што всі внутрашні дадаткі компілююцца пад новым лінкерам. Калі гэты падход стане звычным, выкарыстоўванне таго ж packageManager pin і параметра only-allow у суседніх сервісах дапамагае падтрымваць аднаковасць у всій сістэме. Калі якая-з легасі-інструментаў сапраўды не можа прыміць структуру pnpm, ізолюйце яе, а не відмовляйцеся ад строгіях стандартных налашчэнняў у іншых частках.