Но это относится только к браузерам

Отмахиваться от беспокойства, потому что оно «относится только к браузеру», когда вы даете совет людям, пишущим код для Интернета, — это… Я не могу жалеть слов. Это нелепо. В вашем заголовке написано «интернет», а в «интернете» код для браузеров — это огромный вариант использования, особенно для подавляющего большинства разработчиков, которые вместо того, чтобы в основном писать код для использования OSS другими разработчиками вместо этого пишут код для конечных продуктов.

Этот совет как нельзя более недальновиден с учетом этого и другого важного факта. Инциденты, подобные этому, крайние случаи. Они необычны и редки, и хотя, да, масштаб воздействия и ограниченные возможности для его устранения заставляют в данный момент заманчиво признать жизнеспособность любой тактики, которая предотвратила бы проблему, это также по той же причине. иррациональный.

Ваше предложение по предотвращению неожиданных проблем и повышению производительности в областях с низкой ценностью для бизнеса состоит в том, чтобы принять практику, которая, по моему опыту, будет вызывать проблемы каждый день:

  1. Делая выпуск модульных библиотек более сложным, трудным и трудоемким. Этот подход — я пробовал его в течение 2 лет — означает, что вы должны делать каскадные выпуски каждого отдельного модуля, который зависит от модуля, в котором вы только что исправили ошибку. Это ударит как по основному разработчику библиотеки, так и по разработчикам других библиотек, которые используют их модули — всем придется делать новые выпуски только для того, чтобы получить исправления ошибок. Между прочим, это раздувает причину другого типа проблем с безопасностью.
  2. Увеличение сложности процессов сборки, что связано с бременем реализации и обслуживания этих более сложных процессов сборки. В частности, для борьбы с проблемами, которых не было до того, как зависимости начали объединять свои зависимости (дублированный код и версию этого кода). Вам не нужно не любить процессы сборки в целом, чтобы увидеть, что это компромисс без явного победителя.
  3. Передача проблем с производительностью конечному пользователю с раздутым, дублированным кодом приложения (которое не может прозрачно получать исправления безопасности и производительности в общих транзитивных зависимостях). Ссылаться на улучшение производительности в связи с настройкой разработки или временем сборки пакета бессмысленно, когда компромисс создает проблему в области такой высокой ценности для бизнеса.

Такой подход полностью противоречит основополагающим принципам модульных и распределенных систем, что означает потерю преимуществ. Проблемы с производительностью при загрузке пакетов и запросе пакетов, а также проблемы безопасности внешних пакетов могут быть решены (и решаются с помощью npm, Artifactory и т. д.) другими способами, не вызывать эти проблемы.