Вендорные файлы

Почти ни один проект не пишется с нуля: слайдер, маска для телефона, библиотека для работы с датами, SDK платёжной системы — всё это берут готовым. Такие файлы называют вендорными, от английского vendor — «поставщик». Их ставит менеджер пакетов из реестра: npm кладёт фронтенд-библиотеки в node_modules, Composer кладёт PHP-пакеты в vendor. В старых проектах можно встретить папки js/vendor/ с файлами, скопированными вручную.

Главное правило — вендорные файлы не правят руками. При следующем обновлении зависимостей они перезапишутся, и правка исчезнет. Если библиотеку нужно изменить, это делают через её настройки, наследование, патч, применяемый при установке, или собственный форк.

Отдельный бандл для зависимостей

При сборке фронтенда библиотеки часто выносят в отдельный файл. Собственный код меняется при каждой выкладке, а библиотеки — редко, и браузер может долго держать их в кеше.

// webpack.config.js
optimization: {
  splitChunks: {
    cacheGroups: {
      vendor: {
        test: /[\\/]node_modules[\\/]/,
        name: 'vendors',
        chunks: 'all',
      },
    },
  },
},

Все модули из node_modules попадут в файл vendors. Чтобы кеш сбрасывался только при реальном обновлении библиотек, в имена файлов добавляют хеш содержимого.

Хранить ли в git

Обычно нет. В репозиторий кладут файлы с перечнем зависимостей и точными версиями — package.json и package-lock.json, composer.json и composer.lock, — а на сервере или при сборке устанавливают пакеты по ним. Исключение — плагины и темы WordPress, которые распространяются готовым архивом: внутри них папка vendor лежит уже собранной, потому что на обычном хостинге Composer может быть недоступен.

Безопасность

Уязвимость в зависимости — уязвимость сайта. Команды npm audit и composer audit показывают известные проблемы в установленных версиях, а обновлять зависимости стоит регулярно и небольшими шагами, а не раз в несколько лет.