npm-залежності: аудит, діапазони версій і коли оновлюватись

Навіщо взагалі думати про версії

Кожна залежність — це чужий код у вашому бандлі. npm install тягне транзитивні пакети; дерево швидко стає великим. Без політики оновлень накопичуються вразливості та «неможливі» баги після релізу.

Semver у package.json (коротко)

Запис	Що може змінити npm update
^1.2.3	Мінор і патчі в межах major 1.x
~1.2.3	Лише патчі 1.2.x
1.2.3	Точна версія (якщо lockfile не змінювати вручну)

Реальні діапазони зазвичай фіксує package-lock.json (або pnpm-lock.yaml). Не ігноруйте lockfile у репозиторії для застосунків.

Що запускати регулярно

npm audit
# або
pnpm audit

Аудит показує відомі вразливості — це орієнтир, не абсолютна істина: інколи false positive, інколи треба оновити major.

Практична стратегія

• Патчі безпеки — пріоритетно, після перегляду changelog.
• Мажорні оновлення — окремі PR, тести, staging.
• Залежності без підтримки — план заміни (fork rarely worth it).

Таблиця ризиків (спрощено)

Ситуація	Дія
Critical у продакшені	Терміновий патч або workaround
Low у dev-залежності	Запланувати в наступному спринті
Пакет 3 роки без релізів	Оцінити альтернативи

Класна звичка — один PR = одна логіка змін (наприклад, лише оновлення лінтера). Так простіше відкотити, якщо щось зламається.

Підсумок: lockfile + періодичний audit + обережні мажорні оновлення — мінімум, який окупається вже за кілька місяців.