для чего папка vendor
990x.top
Простой компьютерный блог для души)
Папка vendor — что это?
Приветствую. Данный материал расскажет об одном каталоге, который можно встретить на персональном компьютере/мобильном устройстве.
Вообще vendor — слово, пришло с английского языка, имеет несколько значений: продавец, в компьютерном мире — поставщик железа. Важно понимать, что вендор в некотором смысле это компания/производитель устройств под собственным брендом. Например Samsung — вендор.
Папка vendor на Android
Содержит файлы, который были созданы еще при изготовлении устройства на заводе. Данные файлы — микропрограммы некоторых компонентов, например модуля Wi-Fi, Bluetooth.
Удалять содержимое или саму папку — нежелательно. При желании удалить — сперва создайте резервную копию OS Android.
Каталог операционной системы Андроид (создатель Google).
Папка vendor в Lavarel
Хранит внешние библиотеки, функции которых могут использоваться при написании сайтов, веб-приложений. Некоторые пользователи сообщают, что библиотеки не стоит подключать к проекту.
Lavarel — это некий движок, на основе которого создают современные веб-сайты. Чтобы использовать движок нужно знать язык программирования PHP, быть не совсем начинающем программистом.
Директория проекта. При разработке веб-сайтов или программного обеспечения используют среду разработки (IDE), где собственно и можно заметить данный каталог.
Заключение
Composer — the right way
 | |
У нас давеча сложилась очень интересная и горячая дискуссия с коллегами по поводу использования Composer-а в проектах, над которыми мы работаем. Очень бы хотелось услышать мнение «широкой общественности» по этому вопросу.
Камнем преткновения стал очень простой вопрос:
Стоит ли хранить содержимое папки vendor в наших репозиториях?
Как Вы, в общем наверняка уже догадались, мнения разделились:
Это часть нашего приложения, за которое мы несем ответственность и все зависимоасти должны храниться в одном месте. В данном случае имеетс в виду, что без сторонних библиотек наш код теряет функциональность.
Контр-аргумент: в таком случае, нам надо еще завести в свой репозиторий используемые пакеты уровня операционной системы (apt-get, например). Ведь при использовании аналогичного инструмента в Java — Maven, например, никто же не хранит сторонние зависимости, а только описание оных. Сюда же можно отнести npm, pip и прочие.
Это 3-rd party библиотеки, которые мы просто используем. Желаемого эффекта «неизменности» можно достичь жесткой фиксацией версии библиотеки в composer.json.
Контр-аргумент: отсутствие контроля над разработкой стороннего кода. В случае закрытия или «плохого кода» в проекте вендора, мы теряем функциональность.
Для полноты картины, пройдите, пожалуйста, небольшой опрос.
UPDATE 1
В качестве зависимостей в данном случае имеются в виду официальные SDK для сторонних API, например, или инструменты автоматизации. Т.е. данные пакеты не могут исчезнуть за 1 день.
UPDATE 2
Обсуждение подразумевает хранение вендорского кода ни на прокси для packagist, ни в отдельных форках, а прямо в репозитории с проектом.
UPDATE 3
Под проектом подразумевается некое web-приложение или сервис, но не библиотека, разрабатываемая компанией.
UPDATE 4
В проекте есть и активно используется build для сборки js/css файлов. Это важно, потому что в этот процесс (по мнению автора) должна быть включена сборка php зависимостей.
UPDATE 5
Вышеупомянутые build-ы запускаются на тестовом окружении (или специальном build-сервере) и выкатываются на боевые сервера уже в готовом виде. Это значит что ситуация с разными версиями пакетов между test/stage/live в принципе не возможна.
UPDATE 6 & FINAL
Спасибо всем большое за дискуссию, ссылки и мнения. Эффект от статьи получился именно такой, как того задумал автор.