有没有办法将一个供应商用于具有不同种子的多个项目

Question

我在供应商如何占用太多地方时遇到了问题。由于我的主机对文件和文件夹数量（Inodes）有限制。因此，我找到了一种解决方案，可以通过以下链接在Laravel中使用一个供应商进行多个项目：使用一个供应商文件夹在Laravel 5.2 中进行多个项目。

在以下几行中，我将供应商放入 Projecta 中，然后将其他项目链接到其中。

在 projecta 我做 php工匠迁移时一切都很好：新鲜 - seed 例如，当我尝试同一件事以projectb时，上面的命令有效，直到到达应执行播种机的地方为止。在那里，由于命令试图在 Projecta 中启动 ProjectB 中的播种机，因此发生了一些错误。

播种机错误屏幕截图，

所以我想知道是否有一种方法可以单独制作播种机。

我尝试在composer.json文件上创建一个符号链接，因为它是为供应商文件夹完成的，但它不起作用。

我正在使用Laravel 8

Answer 1

我认为这是一个可怕的想法，除了两个项目共享完全相同的代码库的情况下。

您知道的作曲家使用Composer.json。您的B项目作曲家文件如何确定Laravel中的PSR4自动加载条目，如果将PSR4自动加载条目与项目链接？这可能就是您的种子命令试图在项目中找到类的原因。

作曲家足够聪明，可以缓存下载软件包并重复使用它们，但是我认为每个项目都有自己的依赖项和 state ，这是由Composer.json维护的。和composer.lock on State案件。

如果您在A中更新作曲家但在B中不使用B，则会发生什么？

最后，Composer AutoLoad文件参考您项目中所有满足的依赖项，在这种情况下，（唯一）自动加载文件都会在两个项目中加载，但是如果您所需的软件包并不完全相同，会发生什么？即您在一个项目中有Laravel调试栏，而另一个项目则没有。自动加载生成的文件将引用您其他项目中不存在的软件包。

这不是作曲家的工作方式吗？我错了吗？

Answer 2

在作曲家中，供应商目录（默认情况下，项目树中的供应商）为每个项目。

您询问如何将一个供应商文件夹用于不同的项目。

现在，首先，这绝对不是作曲家所期望的，也不是它的工作原理。参见 manuel glez 答案。简而言之，一个可怕的想法。

当涉及到作曲家时，跨项目共享实际PHP代码的地方不是在供应商目录中，而是在存储库。

只要依赖关系兼容，您就可以使一个项目取决于另一个项目，并使用其供应商/＆lt; vendor＆gt;/＆lt; name＆gt; 文件夹作为存储库。 manuel glez 答案中的评论仍然相同，这需要全面是相同的兼容版本。

但是举一个例子，请参见 Composer Path Repository 具有此

...
├── apps
│   └── my-app
│       └── composer.json
├── packages
│   └── my-package
│       └── composer.json
...

{
    "repositories": [
        {
            "type": "path",
            "url": "../../packages/my-package"
        }
    ]
}

布局每个 ../../ project/a/vendor/＆lt; pkg-vendor＆gt;/＆lt; pkg-name＆gt; in ../ /composer.json ，以便供应商 project/a 中的文件夹可以充当 project/b 的路径存储库。

作为依赖项 composer.json 通常不包含版本，有关 repositories.options.options.versions.versions 的记录说明应用：

当无法从本地VCS存储库推断该版本，或者要覆盖版本时，您可以在声明存储库时使用版本选项：

  {
    “存储库”：[
        {
            “类型”：“路径”，
            “ url”：“ ../ ../ packages/my-package”，
            “选项”： {
                “版本”：{
                    “我/包”：“ 4.2-dev”
                }
            }
        }
    这是给出的
}
 

防止文件重复默认策略的默认策略作曲家是 symlink 软件包目录。确保它有效，然后您在项目B中只有一个符号链接。

好吧，那有多酷？好吧，恕我直言，虽然您仍然放弃作曲家可以为依赖关系管理做什么，但这至少利用本地作曲家存储库，我建议它们共享，而不是完全链接整体供应商文件夹。每个项目仍然都有自己的供应商/Composer 设置，总体而言，所做的工作定义得很好，并且与作曲家本身一致。

这是否有效取决于单个情况。关键点是因为这些本地存储库每个软件包只能提供一个单个版本，因此您只能拥有一个版本。因此，这些版本必须在API级别兼容。

它运行的系统需要支持（相对）符号链接，这通常适用于所述情况。

然后，您可以自动化存储库配置的生产，并将其采用到文件系统布局中。您甚至可以生成存储库并在全局配置文件中更新它们，以便每个项目都会自动更喜欢本地的这些软件包。

$ echo "$(composer config --global home)/config.json"
/home/user/.config/composer/config.json

（compare：（作曲家文档））

请注意所有项目及其依赖性具有便携式途径profor的，然后我想说这应该是非常直接的外壳处理。

要获取已安装的依赖项的实际版本，每个供应商文件夹 供应商/Composer/*已安装*文件。

$ (echo "PACKAGE VERSION"; find .. -type f -path '*/vendor/composer/installed.json' -exec jq -r '.packages[] | .name + " " + .version_normalized ' {} \; | sort -u | sort -k 1b,2V) | cols
PACKAGE                                        VERSION
composer/ca-bundle                             1.3.2.0
composer/composer                              2.3.7.0
composer/metadata-minifier                     1.0.0.0
composer/pcre                                  3.0.0.0
composer/semver                                3.3.2.0
composer/spdx-licenses                         1.5.7.0
composer/xdebug-handler                        3.0.3.0
...
phar-io/manifest                               1.0.1.0
phar-io/manifest                               1.0.3.0
phar-io/manifest                               2.0.1.0
phar-io/manifest                               2.0.3.0
...

（非常旧的安装没有 packages 关键字，您可能需要过滤）

最后，您可能需要一些一些东西来烟雾测试，以便您可以对依赖关系进行防护当您注意到它们时，不兼容问题。