Это ужасная идея; и это даже не то, что вы рекламируете.
Библиотека остается библиотекой, даже если на ней несколько иной слой краски.
Зависимость есть зависимость, даже если вы хотите заявить, что ее распределение между проектами каким-то образом делает зависимость несуществующей. Вы просто перемещаете зависимость для управления в другое место.
Непрерывная интеграция без ограничений — без кто-либо владеющих контрактами и границами компонента — потерпит неудачу с течением времени. Компоненты будут становиться все более и более аморфными, тянущимися в слишком многих направлениях слишком большим количеством команд, чтобы иметь какое-либо единство.
И, боже мой, что вы на самом деле получаете от превращения библиотеки в упражнение по копированию и вставке, кроме приятного заявления «у нас сейчас нет библиотеки»? Какие качественные и количественные изменения в вашем рабочем процессе произошли благодаря этому сдвигу?
В каком мире это инженерное решение, имеющее хоть малейший смысл?? Покажите мне, какие проблемы это решает, и как это соотносится с правильным управлением зависимостями. Показать свою работу. Делайте явные сравнения в различных вариантах использования.
Я понимаю, что избегать и отвергать npm: это не очень хорошее решение! Тем не менее отказ от названий пакетов и библиотек из-за того, что npm плохой, является глубоким непониманием корневой проблемы, а отказ от явных зависимостей в пользу неявных приведет только к еще большим проблемам.
