Есть проект, который я хочу оформить как composer-пакет. Git-репозиторий, в котором хранится код содержит тесты PHPUnit.
То есть, я преследую какую цель:
а). При установке пакета пользователем в vendor через composer, тесты не нужны.
б). При клонировании репозитория разработчиком, тесты нужны.
В документации и интернете только про exclude для архивов нашёл информацию, но это не то.
Ну начнем с того что пользователями вашей библиотеки будут разработчики, которым тесты нужны (как никак, по ним иногда удобно разбираться как что работает). Да и не вижу проблемы в том, что тесты будут включены в репозиторий.
Вообще в composer нету такой возможности насколько я помню. Он просто клонит git-репозиторий себе.
Ну, я как раз и выделил условно "пользователей" (те кому нужно API — для это есть интерфейсы и докблоки, тесты им лишний груз), и "разработчиков" — те которые захотят не просто использовать, а модифицировать и расширять (для них мои тесты могут быть полезны) .
Наверно мне стоит смотреть в сторону системы сборок...
@samizdam, я как "пользователь" библиотек, чаще смотрю на тесты, что бы разобраться в библиотеке. Да и потом, никому от того что там есть тесты ни холодно ни жарко. А разработчики, по вашей классификации, будут клонить напрямую git репозиторий. Можно сделать два репозитория, один для разработчиков, второй - его зеркало подготовленное просто для использования, но я не вижу в этом особо смысла. Для frontend зависимостей смысл имеется. наличие же тестов в проекте никакого оверхэда не принесет.