Мы планируем создать собственный common
комплект для сопоставления сущностей и сервисов для использования в нескольких отдельных приложениях. Пакет должен быть легко модифицировать, запускать, включать и тестировать. Я знаю о Рекомендации по структурированию наборов, но я не знаю, какую стратегию git
использовать, когда дело доходит до разработки.
Должны ли мы создать пакет common
как целостный проект и передать весь репозиторий на наш сервер git, или лучше запустить исходный контроль только для корня из common
bundle и нажать только его содержимое? Я вижу этот подход в пакетах, доступных на github
, но я не знаю, как легко и удобно создавать пакеты таким образом.
php composer.phar create-project symfony/framework-standard-edition demo/ 2.4.1
cd demo
(например, src/Company/DemoBundle
)
php app/console generate:bundle
cd src/Company/DemoBundle/
src/Company/DemoBundle
git init
touch README.md
git add .
git commit -m "initial commit"
git remote add origin https://github.com/YourAccount/DemoBundle.git
git push -u origin master
src/Company/DemoBundle/composer.json
:
{
"name" : "company/demobundle",
"description" : "A demo bundle",
"type" : "symfony-bundle",
"authors" : [{
"name" : "demo",
"email" : "[email protected]"
}],
"keywords" : [
"demo bundle"
],
"license" : [
"MIT"
],
"require" : {
},
"autoload" : {
"psr-0" : {
"Company\\DemoBundle" : ""
}
},
"target-dir" : "Company/DemoBundle",
"repositories" : [{
}],
"extra" : {
"branch-alias" : {
"dev-master" : "some_version-dev"
}
}
}
Теперь у вас есть базовая структура вашего пакета
composer.json:
[...]
"require" : {
[...]
"company/demobundle" : "dev-master"
},
"repositories" : [{
"type" : "vcs",
"url" : "https://github.com/Company/DemoBundle.git"
}],
[...]
делать:
curl -sS https://getcomposer.org/installer | php
php composer.phar update company/demobundle
Приложение/AppKernel:
new Company\DemoBundle\CompanyDemoBundle(),
src/Company
, а затем вручную установить егоВы можете разработать и протестировать свой пакет в своем первом проекте и использовать его с github и composer во втором проекте.
Важным моментом для вас является то, что вы можете зафиксировать свое репо у /vendor. В самом деле, композитор создает второй пульт, называемый "композитор" для каждого пакета (или пакета), который ссылается на репо пакета, чтобы вы могли работать над ним в рабочем контексте.
Поэтому хорошей практикой является регистрация вашего пакета в вашем composer.json для всех ваших проектов и передача из вашего /vendor/MyCompany/MyBundle
из любого проекта.
В качестве доказательства просто запустите git remote -v
из любого пакета в вашем поставщике.
Плохая практика заключается в том, чтобы рассмотреть ваш комплект как отдельный проект и иметь с ним символические ссылки. Основная причина, по которой это неверная практика, заключается в том, что вы не сможете объявлять зависимости с вашим пакетом. Кроме того, у вас возникнут трудности с развертыванием ваших проектов.
/src
или в каталоге /vendor
при запуске? Когда я включу этот комплект в другой проект, он будет в /vendor
но где я должен их генерировать при запуске?
composer update
. Теперь вы должны увидеть свой пустой пакет в папке vendor, и вы можете работать в нем. Если вы хотите, чтобы ваш пакет был общедоступным, добавьте его в Packagist.