1. Не совсем понял, о чем ты. У тебя предполагается один phar-файл - composer.phar
2. Чтобы подключить к проекту twig, достаточно прописать в composer.json:
PHP:
{
"require": {
"twig/twig": "1.12.*@dev"
}
}
Т.к.
твиг уже есть на пакагисте.
Если захочешь, например, форкнуть твиг и использовать свою версию, то тебе нужно будет прописать к своему форку адрес репозитория:
PHP:
{
"require": {
"twig/twig": "1.12.*@dev"
},
"repositories": [
{
"type": "vcs",
"url": "https://github.com/fixxxer/Twig"
},
]
}
Если тебе нужно
использовать репозиторий, для которого нет настроенного composer.json, то тебе надо прописать нужные настройки в своем composer.json:
PHP:
{
"require": {
"twig/twig": "1.12"
},
"repositories": [
{
"type":"package",
"package":{
"name":"twig/twig",
"version":"1.12",
"source":{
"type":"git",
"url":"https://github.com/fixxxer/Twig",
"reference":"master"
},
"autoload": {
"psr-0" : {
"Twig_" : "lib/"
}
}
}
},
]
}
В секции autoload я определяю, как должны загружаться классы твига композеровским автолоадером.
3. Да, есть такое дело. Я рассматриваю такой вариант, в котором тебе не надо вообще таскать папку vendor куда-либо. Она создается и обновляется на сервере композером на основе прописанных конфигов. С каждым php composer.phar update будут загружаться указанные в конфиге версии пакетов (если версии отличаются от установленных).
Конечно, избежать клонирования лишних файлов в этом случае не удается. Если они мешают, можно написать обработчик на post-update-cmd, который удалит все лишнее. Но, зачем? Только из соображений эстетики? Доки и тесты же не мешают коду работать?
Тебе надо представить, что ты пользователь. Запускаешь программу установки, она ставит тебе нужный пакет. Пакет работает без лишних плясок с бубном. Что еще надо для счастья?
Тут предлагают возможность устанавливать пакет из удаленного zip-архива. Но, готовить для всех пакетов архивы, в которых лежат только нужные тебе файлы устанешь.
накой мне на проде тесты и документация