drupal/core与drupal/core-推荐

Question

我有一个关于drupal/core和drupal/core-recommended的问题。因此，drupal/core-recommended使用包的固定版本，并使用相应的核心版本进行测试。是的，这确实是有意义的，这可以防止不同版本的Symfony包的版本差异所引入的bug。

但是另一方面，假设您使用composer安装模块的dev版本或任何其他第三方库，这显然需要一个不同于drupal/core-recommended的Symfony组件版本，这些锁定版本的核心依赖项将导致麻烦，因为第三方库/模块由于版本冲突而无法安装。

那么，在使用drupal/core-recommended时，如何处理这种情况呢？

Answer 1

它是“推荐的”，如“推荐的，以避免与依赖相关的麻烦与核心。”

Drupal核心(以及一些提供的模块，但不是所有模块)都有各种各样的自动化测试，可以运行这些测试，以确保一切正常运行。但是，Drupal也需要运行依赖项。如果使用未经测试的依赖项的不同版本，可能会出现错误，测试可能无法通过。core-recommended包含用于测试给定版本的Drupal的特定依赖项。

通过使用core-recommended，您可以获得与发布该版本的Drupal相同的依赖关系，而Drupal只有在这些测试通过后才会释放。因此，在部署站点时，您可以更加自信，因为您知道核心+依赖关系的组合是根据测试进行验证的。

假设您使用composer安装了模块或任何其他第三方库的dev版本，它显式地需要一个不同于drupal/core推荐的Symfony组件的版本，

贡献模块很少需要Symfony组件的特定版本。当您确实需要使用这样的模块并从core/recommended切换到core时，您可能会遇到一些与Symfony相关的或其他与依赖相关的bug，因为有些依赖项可能需要对核心进行尚未完成的更改。因此，当您这样做，您现在负责运行测试，如果您遇到错误，您可能必须搜索核心问题队列和应用补丁，等等。

至于dev模块，我们从来不建议在生产中安装dev模块，因此，每当您安装dev模块时，您都要自己负责测试。

TLDR:推荐的意思是“推荐”，因为它通过了测试。这些是推荐的依赖项，因为已知它们可以工作，但是如果您愿意，当然可以尝试使用其他依赖项。但是，如果您不使用推荐的依赖项，然后发现一个bug，然后想，“嘿，内核坏了，让我们提交一个问题！”，您应该首先使用core-recommended检查，以确保这个问题不是特定于需要删除core-recommended的contrib模块/依赖项。

Answer 2

让我们来看看自述文件 of drupal/core-recommended。这基本上解释了一切。

需要此项目而不是drupal/核心子树拆分，以确保来自drupal/core的所有依赖项都将包含在您的Drupal站点中，其版本与您当前正在使用的版本所测试的版本完全相同。不使用该项目的后果是，当您使用Composer升级Drupal站点时，Drupal的依赖项可能“浮出”到更新的版本，而不是使用Drupal进行测试。有时，新的依赖版本会在Drupal中引入bug。虽然这类错误通常会很快得到纠正，但作为第一批遇到这些错误之一的人之一仍然会带来很大的干扰。使用推荐的依赖项可以避免此问题，只使用已经用Drupal测试过的依赖关系版本。

也在使用作曲家安装和管理Drupal上的文档中。

运行composer require drupal/core-recommended将Drupal安装到您喜欢的目录结构中。如果您不想将所有Drupal的依赖项锁定到已知的好版本，也可以需要drupal/core包。