3

我注意到 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 呢？另一方面，它使更新成为一个问题，因为您可能已经更改了一些内容并希望它们在更新期间不会被覆盖。那么为什么不使用带有私有存储库的简单作曲家包呢？

为什么它是这样完成的？这是好习惯吗？它成为或不是良好做法的原因是什么？

4

1 回答 1

3

Spark 它不是作曲家包，因为它是一项高级功能，因此您必须在某处添加存储库，这样作曲家就能够找到它并像普通作曲家包一样安装。Spark 自行更新，因此可操作性由工匠命令完成。

关于良好实践，您如何构建文件并不重要，最终是否有效，这没有性能问题，并且可以以不同的方式完成。

总之，这是因为你不能直接从作曲家下载火花。

于 2017-02-11T10:33:09.397 回答