Composer 和本地依赖项

Question

我想使用 Composer 来管理我自己在工作中使用的私有库，并将它们用于工作中的 Intranet 项目。

根据公司规则不将代码发布到 packagist 或 github；可以这么说，所有代码都将保留在我们自己的围墙内。

我已经弄清楚如何将库单独包含到我的 Intranet Web 应用程序中：

网页应用的composer.json

{
    "name": "myapp/appname",
    "description": "app that uses some of my libraries",
    "require": {
      "tmorton/dataaccessobjects": "^1.0.0"
    },
    "repositories": [
      {
        "type":"vcs",
        "url":"//path/to/library"
      }

    ]
}

我的问题是这个数据访问对象的集合依赖于我的 crud 库。

所以看来我应该可以requiredataaccessobjects库中composer.json中的crud库了：

composer.json 用于数据访问对象

{
    "name": "tmorton/dataaccessobjects",
    "description": "Data Access Objects for a set of specific tables",
    "type": "library",
    "license": "proprietary",
    "repositories": [
      {
        "type": "path",
        "url":"//path/to/crud/library"
      }
    ],
    "minimum-stability": "dev",
    "require": {
      "tmorton/crud": "^2.0.0"
    }
}

我的 DAO 对象被克隆到 app/vendor 中，但 Crud 没有被引入。

我看到的所有文档都谈到了发布到第三方位置，但没有提到来自本地来源。

我当然可以这样做；但它破坏了管理依赖项的整个想法（我不应该知道此时需要哪个版本的 crud）

网页应用的composer.json

{
    "name": "myapp/appname",
    "description": "app that uses some of my libraries",
    "require": {
      "tmorton/dataaccessobjects": "^1.0.0",
      "tmorton/crud": "^2.0.0"
    },
    "repositories": [
      {
        "type":"vcs",
        "url":"//path/to/dao/library"
      },
      {
        "type": "path",
        "url":"//path/to/crud/library"
      }

    ]
}

我希望有人能补充一些我似乎遗漏的概念。

---

suggested question 的答案似乎表明type: "package" 不起作用。我没有使用type: "package"。

包类型用于非作曲家依赖。如果使用这种类型，Composer 甚至不会在已定义的包源中查找 composer.json 文件，您需要在项目 composer.json 中的包声明中包含有关包的所有必需信息

我收集到的是，无论您做什么，作曲家 - 本身 - 都不会费心查找包含项目的依赖关系。在抓取 3rd 方的东西时它会以某种方式起作用，但显然还有其他东西在做这项工作。我猜是主机本身？

Answer 1

我发现运行 Intranet 会带来一些管理开销，这也是我停止使用它的原因。

在您的情况下，我会建议：

1. 使用 git 进行内部包：
   您在某处有一个私人 git 存储库，并要求使用 repository directive of composer

   “要求”：{
   “我的/包”：“开发主”
   ...
   },
   “存储库”：[
   {
   “类型”：“git”，
   "url": "git@bitbucket.org:my/package.git"
   }
   ]

当然不要提交供应商目录，但要提交 composer.lock。

更新：
请注意，您还需要在项目的 composer.json 的存储库块中添加私有子包的存储库。 因此，当 my/package 需要另一个私有包 my/package2 时，请将 thismy/package2 也添加到您的项目 composer.json 的 repositories 块中。

1. 使用构建进行部署
   使用 deployer 之类的工具，您可以轻松地在生产环境中运行 composer，并在所有运行后符号链接到成功的构建/发布。
   在这里，您还依赖于生产机器上的 composer，但部署程序通常在 web 根目录之外安装 phar 本身。
   如果这不合适，您还可以使用 deployer 进行本地构建并通过 rsync 同步到您的生产系统： https://deployer.org/docs/advanced/deploy-strategies.html#build-server
   在这里，您在构建目录中从 git 本地签出，在本地运行 composer 并通过 rsync 推送到生产环境。