Почему Laravel Spark устанавливается в корень проекта, а затем подключается к поставщику?

Я заметил (для меня) странный шаблон, который Laravel Spark использует для установки себя, и я не могу понять, почему это следует делать или считается хорошей практикой.

Поведение

Учитывая, что мы создаем приложение Spark в каталоге /var/acme-spark.

Во-первых, установщик Spark настраивает приложение Laravel. После этого он загружает/устанавливает все файлы Spark (исходный код PHP, ресурсы внешнего интерфейса, такие как файлы LESS и JS, шаблоны блейдов и так далее) в каталог с именем spark в корне проекта, то есть в /var/acme-spark/spark. Затем он обновляет composer.json, чтобы он содержал следующее:

{
// ...
    require: {
        // ...
        "laravel/spark": "*@dev"
    }
// ...
    "repositories": [
        {
            "type": "path",
            "url": "./spark"
        }
    ]
}

Что в основном означает: «Возьмите каталог spark и относитесь к нему как к репозиторию поставщиков. Затем создайте символическую ссылку для каталога spark в поставщиках».

Символическая ссылка действительно выглядит следующим образом:

user@machine:~$ cd /var/acme-spark/vendor/laravel
user@machine:/var/acme-spark/vendor/laravel$ ls -l
cashier
framework
homestead
spark -> ../../spark

Загадочная часть

Теперь это озадачивает, так как это дает вам полный контроль над всем, что является ядром Spark, так зачем вообще использовать композитор? С другой стороны, это делает обновление проблемой, поскольку вы могли что-то изменить и ожидать, что они не будут перезаписаны во время обновления. Так почему бы тогда не использовать простой пакет composer с приватным репозиторием?

Почему это сделано именно так? Это хорошая практика или нет? Каковы причины того, что это является или не является хорошей практикой?


laravel composer-php laravel-spark
person thormeier    schedule 03.02.2017    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Spark — это не пакет композитора, а его премиальная функция, из-за этого вы должны где-то добавить репо, и таким образом композитор сможет найти его и установить, как обычный пакет композитора. Spark обновляет сам себя, чтобы его ремонтопригодность выполнялась командой artisan.

Что касается хорошей практики, то, как вы создаете свои файлы, не имеет значения, работает ли в конце, это не имеет проблем с производительностью, и все можно сделать по-разному.

В заключение, причина этого в том, что вы не можете загрузить spark напрямую из композитора.

person Kiko Seijo    schedule 11.02.2017
comment
Так и думал, если честно. Кажется, что это какой-то обходной путь, чтобы предоставить исходный код через композитор и сохранить его в vendor/, без необходимости публиковать его на packagist или выполнять административную работу, добавляя множество ключей SSH в пользовательский репозиторий Satis или что-то подобное. - person thormeier; 16.02.2017