Дистрибутивы Linux сталкиваются с проблемой увеличения зависимостей проектов, хотя количество зависимостей для кода Python, Perl и Ruby сохраняется В разумных пределах проекты JavaScript делятся на очень маленькие библиотеки, часто выполняющие простую функцию.
В репозитории NPM уже более миллиона пакетов и типичные приложения ссылка на сотни зависимостей, которые, в свою очередь, имеют свои собственные зависимости, что затрудняет поддержку и распространение традиционных пакетов с приложениями JavaScript в дистрибутивах Linux.
Из-за тесной взаимосвязи зависимостей библиотек JavaScript обновление любого пакета такими библиотеками в дистрибутиве он может сломать другие пакеты.
Привязки версий усугубляют проблему: одной библиотеке может потребоваться одна версия зависимости для стабильной работы, а другой может потребоваться другая.
Для работы многих проектов требуются последние версии библиотек, которые не всегда соответствуют требованиям стабильности дистрибутива (в экосистеме Node.js практикуется непрерывная разработка с использованием последних версий фреймворков, а дистрибутив нуждается в поддержке в течение нескольких лет).
Попытки исправить версии пакетов только в дистрибутиве приводят к увеличению устаревших версий в репозитории, который не обновлялся годами. Нарушение обслуживания одного пакета отрицательно сказывается на многих других пакетах и создает еще больше проблем.
Кроме того, lперекрестные зависимости приводят к тому, что многие библиотеки Node.js невозможно удалить из системы, что, в свою очередь, не позволяет вам удалить другие программы Node.js.
Чтобы решить эту проблему, проект Fedora недавно одобрил план по прекращению формирования по умолчанию отдельных пакетов с библиотеками, используемыми в проектах на основе Node.js.
Он решил, начиная с Fedora 34, поставлять только базовые пакеты для Node.js с интерпретатором, заголовками, первичными библиотеками, двоичными файлами и базовыми инструментами управления пакетами (NPM, yarn).
В приложениях репозитория Fedora, использующих Node.js, разрешается встраивать все существующие зависимости в пакет без разделения и разделения библиотек, используемых в отдельных пакетах.
Встраивание библиотек избавит от небольшого беспорядка в пакетах, упростит обслуживание пакетов (ранее сопровождающий тратил больше времени на просмотр и тестирование сотен пакетов с библиотеками, чем в основном пакете с программой), убережет инфраструктуру от конфликтов библиотек и решить проблемы со связью с версиями библиотек (сопровождающие будут включать в пакет проверенные и производственные версии).
Обратной стороной интеграции станет усложнение процесса внесения исправлений. уязвимости в библиотеках, которые потребуют согласованной работы сопровождающих всех пакетов, в которые входит уязвимая библиотека. Существует опасность, что пакет забудет обновить уязвимую встроенную библиотеку, и пакет останется незамеченным.
Разработчики Debian также обсуждает переход на аналогичную модель интеграции зависимостей пакетов. Помимо Node.js в обсуждении затрагиваются вопросы создания пакетов для платформы Kubernetes и проектов на языках PHP и Go, для которых существует тенденция к разделению на небольшие зависимости. Решение еще не принято, но есть надежда, что со временем проблема только усугубится, и рано или поздно проект будет вынужден что-то делать.
Веб-интерфейс gsa (Greenbone Security Assistant) для сканера безопасности gvm (Greenbone Vulnerability Management) приводится в качестве примера проблем, с которыми сталкиваются разработчики пакетов.
Поставляемая Debian версия gsa оказалась несовместимой с более новыми версиями gvm, но было невозможно обновить gsa до текущей версии, поскольку она содержит значительные изменения и использует npm для загрузки необходимых библиотек Node.js.
Запрошенных библиотек слишком много, и для их обслуживания требуется создание новых пакетов в Debian, поскольку правила Debian запрещают загрузку внешних компонентов во время процесса сборки.
источник: https://lwn.net/
Эта фрагментация фреймворков и библиотек в ECMAscript вышла из-под контроля.
Хорошая статья.