Как стать автором
Обновить

Комментарии 9

В контексте управления зависимостями полезно было бы ещё упомянуть про npm audit — команда сканирует зависимости и ищет уязвимости в используемых версиях библиотек.

Как раз планирую написать про надежность и безопасность в следующем посте.

я конечно так и не понял причем тут nodejs и js? укажите это тогда в статье

Так как js сам по стандарту нечего не знает о файлах, сетях etc, используется nodejs имплементирующий commonJS. С его помощью работает большенство тулзов под js, упаковщиков и в целом весь инструментарий современного фронта, идет через npx, npm, yarn etc.
Ну а js, потому, что речь про js ))

НЛО прилетело и опубликовало эту надпись здесь
А как можно ручаться за то, что находится вне вашего контроля?

Никто от вас этого и не может ожидать — правила экосистемы достаточно просты и известны всем участникам. Конечно, риски присутствуют всегда и никто не защищен от того, что автор какой-то корневой библиотеки вдруг выпустит patch-обновление с нарушением обратной совместимости, но по факту такое случается крайне редко, а если и случается, то достаточно быстро обнаруживается и исправляется. Вы можете снизить риск, если будете стараться использовать только надежные проверенные библиотеки. Даже в человеческом организме иногда встречаются раковые клетки, такова жизнь, но это не повод жестко фиксировать все зависимости, идти против экосистемы, снижать эффективность управления зависимостями и порождать неприятные побочные эффекты.


Если же говорить про конечные продукты (веб-приложения или серверы), то снижение рисков как раз таки достигается автотестами и какие-либо деградации не должны выходить на уровень пользователя. Если же программа выполняется на Node.js и ставится глобально (npm i -g), то скорее всего это какой-то инструмент разработки, который не имеет столь жестких требований по надежности и даже, если что-то сломается, то это можно будет исправить без наступления критически последствий.


Особенно актуально это становится, если вы используете зависимости версии 0.х.х, в которых по-умолчанию, апи не стабильно и может измениться в любой момент.

По этой причине semver по особому относится к версиям начинающимся с нуля и сильно ограничивает диапазон обновлений (писал об этом в первом посте). Такие зависимости как раз имеет смысл фиксировать в манифесте.

НЛО прилетело и опубликовало эту надпись здесь
Беда в том, что бывают и довольно популярные пакеты, которые могут класть болт на semver. Спасибо автору за то, что он несколько раз повторил и выделил жирным шрифтом, что надо всё тестировать и проверять даже после минорных апдейтов.

Спасибо, что собрали все это в 1 статью.
Постоянно гуглил про эти вещи, тк еще не запомнил все. Много очень разрозненной информации.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий