Чистое развертывание приложения при использовании Composer
Я начал использовать Composer для нового PHP-приложения (в нем используется несколько фреймворков и API-интерфейсов, таких как Laravel, Smarty и т. Д.), И в разработке все хорошо.
Тем не менее, я не слишком уверен в том, как мне развернуть это на живом производственном сервере. Подкаталоги соответствующих модулей под /vendor каталог, кажется, включает в себя множество вещей, которые я обычно не включаю в приложение (например, демонстрационные файлы, установочные файлы, документация и т. д.). Это нормально, или создатели этих пакетов неправильно поняли, как создать пакет Composer?
Существует ли стандартный подход для создания чистого развертывания приложения, который включает только необходимые файлы дистрибутива, а не остальную часть материала, который не связан и даже не должен присутствовать (даже по соображениям безопасности)?
Я спрашиваю о наиболее распространенном рабочем процессе, или, может быть, о конкретной команде или конфигурации в composer.json Я должен смотреть, чтобы добиться этого.
Решение
Я бы сделал две рекомендации, которые охватывают большинство ваших забот.
1)
Используйте обновление композитора —no-dev, чтобы исключить любые зависимости для разработки только из файла блокировки. Или настройте ваши требования в composer.json, чтобы добиться того же.
Теоретически разработчики пакетов должны поддерживать чистоту рабочей версии (например, не включая все тесты phpunit). Однако, да, это вполне нормально, когда в библиотеке вендоров много «запутанности», в основном потому, что концепция сборки в PHP относительно не распространена, поэтому «источники» и «цели» смешаны.
Демоверсии и файлы readme по-прежнему являются необходимой частью «дистрибутивной» версии компонента, поэтому они по-прежнему будут присутствовать, если вы укажете no-dev, что просто говорит: «Я не занимаюсь разработкой». этот пакет, я просто потребляю его «.
Такое ощущение, что есть отсутствующая функция композитора: на один уровень выше этого, который действительно является сверхчистым минимизированным пакетом развертывания.
2)
Держите свою библиотеку вендора над корнем сети.
Это предотвращает любой нежелательный просмотр в библиотеке поставщика и устраняет любые проблемы безопасности посетителей сайта, исследующих ваши библиотеки (если это то, о чем вы по праву беспокоились).
например Я обычно использую
domain
/api
/etc
/vendor
/www
/js
/css
/images
/index.php
/foo
/bar.php
куда www веб-корень виртуального хоста
Все скрипты начального уровня находятся в вашем корне сети как обычно, и путь к автозагрузке в ../vendor/autoload.php
Или, конечно, www / может быть корневой папкой laravel, если вы используете Laravel для своего сайта, а также API.
Api может разместить отдельный хост для ваших API Laravel, если они сделаны отдельно от «плоского» сайта.
(Я держу другие папки выше корня сети build, docs, src для SASS, JS, Grunt и т. д., etc может безопасно хранить любые конфигурации, пароли, ключи и т. д.).
3)
Если вы по-прежнему недовольны багажом, то, как предполагает другой комментатор, вы захотите взглянуть на процесс сборки, который все проясняет. Это может быть сложным, хотя и трудно поддерживать!
например Вы можете создать локальную папку для развертывания www (например, обновление композитора, а также любые задачи grunt, установки bower, публикацию laravel / artisan и т. д.), затем обрезать ее обратно (пользовательские сценарии, которые вам придётся создать) и зафиксировать это в отдельном файле. хранилище, представляющее опубликованную плоскую цель развертывания. Это то, что вы бы развернули на своем сайте.
Это должно быть автоматизировано, иначе вы перестанете делать это примерно через третий раз 🙂
Но … вы должны спросить, почему еще вы хотели бы сократить библиотеки продавца. Дисковое пространство? Они не такие большие. Общая чистота? Считайте папки черными ящиками и просто читайте документы по API. т.е. не смотри 🙂
Другие решения
Других решений пока нет …