“替换”属性如何与作曲家一起工作？

小开

最佳答案

Composer 文档给出了两个基本的例子，我将试着解释:

列出由此包替换的包。这允许您分叉一个包，使用其自己的版本号以不同的名称发布它，而需要原始包的包继续使用您的分叉，因为它替换了原始包。

假设您的软件使用 original/library和 other/package，它们本身也需要 original/library。

现在您认为 original/library需要集成一个特性，但是维护人员不会让您的建议发生在他们的包中。您决定将这个库命名为 better/library，并标记为一个新版本。

回到你的软件上。当然，它应该开始使用 better/library，所以您需要它，但是 other/package仍然需要 original/library-代码复制！如何让另一个包使用您的 better/library而不使用它，并且只改变 comper.json (您仍然兼容那个 original/library，所以它应该可以工作) ？

在 composer.json中添加一个替换键:

"replace": {
"original/library":"1.0.2"
}

现在 Composer 知道，在解决 other/package的依赖关系时，来自 better/library的任何包都和 original/library一样好。

这对于包含子包的包也很有用，例如主 Symfony/Symfony 包包含所有 Symfony 组件，这些组件也可以作为单独的包使用。如果您需要主包，它将自动满足任何一个单独的组件的要求，因为它替换它们。

同样的规则，略有不同的角度: 对于其他需要某些特性的组件来说，需要框架的组件是一种很好的方法。但是，如果您需要在您的软件中安装完整的框架，以及另一个库，后者也需要该框架的一个组件，则框架的 replace声明允许 Composer 不必安装该组件两次，因为该组件已经包含在完整的框架中。

注意: 替换版本中的占位符通常是不好的

在我最初的回答中，我建议:

"replace": {
"original/library":"1.*"
}

这样做的后果是: Composer 现在将把你的库版本1.0.0视为和原库的任何版本1.x 一样好，即使他们修复了一些东西或者添加了一些特性，有朝一日发布了1.2.34版本。这也意味着，如果你的 other/package有一天得到一个更新，需要 original/library:^1.1，在你的库的替换仍然是活跃的，并声明它可以替换任何版本的 1.*，即使没有你更新任何内部-它不能，你的旧代码将永远不会实现新的功能，原来的库没有你做一些工作，但替换状态正是这一点。

所以本质上: 在替换版本中避免通配符版本！如果你使用它们，你对未来做了一个陈述，你不能知道或预测(除非你能控制 original/library，但即使那样也要非常小心)。始终使用您知道并能够完全重新实现的特定版本的 original/library。