我注意到(对我来说)Laravel Spark正在使用一个奇怪的模式来安装自己，我真的不明白为什么应该这样做，或者被认为是一种好的做法。
行为
假设我们在目录/var/acme-spark中创建了一个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呢？另一方面，它使更新成为一个问题，因为您可能已经更改了内容，并希望它们在更新过程中不会被覆盖。那么，为什么不使用一个带有私人存储库的简单composer包呢？
为什么要这样做？这是不是好的做法？是什么原因导致它是或不是良好的实践？
Spark不是一个composer包，因为它是一个高级功能，因此您必须在某个地方添加repo，这样composer就可以像普通的composer软件包一样找到并安装它。Spark更新自身，使其可移植性由artisan命令完成。
关于良好实践，如何构建文件并不重要，最终是否有效，这没有性能问题，可以用不同的方式完成。
总之，这是因为你不能直接从作曲家那里下载火花。