composer.json 模式#

本章将解释 composer.json 中可用的所有字段。

JSON 模式#

我们有一个 JSON 模式 来记录格式，也可以用来验证您的 composer.json。事实上，它被 validate 命令使用。您可以在以下位置找到它：https://getcomposer.org.cn/schema.json

根包#

根包是由您项目根目录下的 composer.json 定义的包。它是定义项目需求的主要 composer.json。

某些字段只适用于根包上下文。例如，config 字段。只有根包可以定义配置。依赖项的配置将被忽略。这使得 config 字段成为 root-only（仅限根目录）。

注意： 包可以是根包，也可以不是，这取决于上下文。例如，如果您的项目依赖于 monolog 库，则您的项目是根包。但是，如果您从 GitHub 克隆 monolog 来修复其中的一个 bug，那么 monolog 就是根包。

属性#

name#

包的名称。它由供应商名称和项目名称组成，用 / 分隔。示例

  • monolog/monolog
  • igorw/event-source

名称必须是小写，并由用 -、. 或 _ 分隔的单词组成。完整名称应匹配 ^[a-z0-9]([_.-]?[a-z0-9]+)*/[a-z0-9](([_.]|-{1,2})?[a-z0-9]+)*$。

name 属性对于发布的包（库）是必需的。

注意： 在 Composer 2.0 版本之前，名称可以包含任何字符，包括空格。

description#

包的简要描述。通常只有一行长。

对于发布的包（库）是必需的。

version#

包的版本。在大多数情况下，这是不需要的，应该省略（见下文）。

这必须遵循 X.Y.Z 或 vX.Y.Z 的格式，并带有一个可选的后缀 -dev、-patch（-p）、-alpha（-a）、-beta（-b）或 -RC。补丁、alpha、beta 和 RC 后缀也可以后跟一个数字。

示例

  • 1.0.0
  • 1.0.2
  • 1.1.0
  • 0.2.5
  • 1.0.0-dev
  • 1.0.0-alpha3
  • 1.0.0-beta2
  • 1.0.0-RC5
  • v2.0.4-p1

如果包仓库可以从某个地方推断版本（例如 VCS 仓库中的 VCS 标签名称），则为可选。在这种情况下，也建议省略它。

注意： Packagist 使用 VCS 仓库，因此上述声明对 Packagist 也是非常真实的。自己指定版本很可能会在某个时候由于人为错误而导致问题。

type#

包的类型。默认为 library。

包类型用于自定义安装逻辑。如果您有一个需要特殊逻辑的包，您可以定义一个自定义类型。这可以是 symfony-bundle、wordpress-plugin 或 typo3-cms-extension。这些类型都将特定于某些项目，并且需要提供一个能够安装该类型包的安装器。

开箱即用，Composer 支持四种类型

  • library： 这是默认值。它将文件复制到 vendor 目录。
  • project： 这表示一个项目而不是一个库。例如，Symfony 标准版 这样的应用程序外壳、Silverstripe 安装程序 这样的 CMS 或作为包分发的完整应用程序。例如，这可以被 IDE 用来提供在创建新工作空间时初始化的项目的列表。
  • metapackage： 一个包含需求的空包，它将触发其安装，但不会包含任何文件，也不会写入任何内容到文件系统。因此，它不需要 dist 或 source 密钥即可安装。
  • composer-plugin： 类型为 composer-plugin 的包可以为具有自定义类型的其他包提供安装器。在 专门的文章 中了解更多信息。
  • php-ext 和 php-ext-zend： 这些名称保留用于用 C 语言编写的 PHP 扩展包。不要对用 PHP 编写的包使用这些类型。

只有在安装过程中需要自定义逻辑时才使用自定义类型。建议省略此字段，让它默认为 library。

keywords#

包相关的关键字数组。这些可以用于搜索和过滤。

示例

  • logging
  • events
  • database
  • redis
  • templating

注意：某些特殊关键字会触发 composer require（不带 --dev 选项）以提示用户是否希望将这些包添加到 require-dev 而不是 require 中。这些是：dev、testing、static analysis。

注意：字符串中允许的字符范围仅限于 Unicode 字母或数字、空格 " "、点 .、下划线 _ 和破折号 -。（正则表达式：'{^[\p{N}\p{L} ._-]+$}u'）使用其他字符将在运行 composer validate 时发出警告，并会导致包在 Packagist.org 上无法更新。

可选。

homepage#

项目网站的 URL。

可选。

readme#

自述文档的相对路径。默认为 README.md。

这对不在 GitHub 上的包很有用，因为对于 GitHub 包，Packagist.org 将使用自述文件 API 获取 GitHub 检测到的自述文件。

可选。

time#

版本的发布日期。

必须采用 YYYY-MM-DD 或 YYYY-MM-DD HH:MM:SS 格式。

可选。

license#

包的许可证。这可以是字符串或字符串数组。

最常见许可证的推荐符号是（按字母顺序）

  • Apache-2.0
  • BSD-2-Clause
  • BSD-3-Clause
  • BSD-4-Clause
  • GPL-2.0-only / GPL-2.0-or-later
  • GPL-3.0-only / GPL-3.0-or-later
  • LGPL-2.1-only / LGPL-2.1-or-later
  • LGPL-3.0-only / LGPL-3.0-or-later
  • MIT

可选，但强烈建议提供它。更多标识符列在 SPDX 开源许可证注册表 中。

注意： 对于闭源软件，您可以使用 "proprietary" 作为许可证标识符。

一个示例

{
    "license": "MIT"
}

对于一个包，当有多种许可证可供选择时（“析取许可证”），可以将多个许可证指定为数组。

析取许可证示例

{
    "license": [
        "LGPL-2.1-only",
        "GPL-3.0-or-later"
    ]
}

或者，它们可以被 “or” 分隔并用括号括起来；

{
    "license": "(LGPL-2.1-only or GPL-3.0-or-later)"
}

同样，当需要应用多个许可证时（“合取许可证”），它们应该被 “and” 分隔并用括号括起来。

authors#

包的作者。这是一个对象数组。

每个作者对象可以具有以下属性

  • name： 作者的姓名。通常是他们的真名。
  • email： 作者的电子邮件地址。
  • homepage： 作者网站的 URL。
  • role： 作者在项目中的角色（例如，开发人员或翻译人员）

一个示例

{
    "authors": [
        {
            "name": "Nils Adermann",
            "email": "[email protected]",
            "homepage": "https://www.naderman.de",
            "role": "Developer"
        },
        {
            "name": "Jordi Boggiano",
            "email": "[email protected]",
            "homepage": "https://seld.be",
            "role": "Developer"
        }
    ]
}

可选，但强烈建议。

support#

有关项目的各种支持信息。

支持信息包括以下内容

  • email： 支持的电子邮件地址。
  • issues： 问题跟踪器的 URL。
  • forum： 论坛的 URL。
  • wiki： wiki 的 URL。
  • irc： 支持的 IRC 频道，例如 irc://server/channel。
  • source： 浏览或下载源代码的 URL。
  • docs： 文档的 URL。
  • rss： RSS Feed 的 URL。
  • chat： 聊天频道的 URL。
  • security： 漏洞披露策略 (VDP) 的 URL。

一个示例

{
    "support": {
        "email": "[email protected]",
        "irc": "irc://irc.freenode.org/composer"
    }
}

可选。

funding#

一个 URL 列表，用于向包作者提供资金，用于维护和开发新功能。

每个条目包含以下内容

  • type： 资金类型，或提供资金的平台，例如 patreon、opencollective、tidelift 或 github。
  • url： 包含详细信息和资金包方式的网站的 URL。

一个示例

{
    "funding": [
        {
            "type": "patreon",
            "url": "https://www.patreon.com/phpdoctrine"
        },
        {
            "type": "tidelift",
            "url": "https://tidelift.com/subscription/pkg/packagist-doctrine_doctrine-bundle"
        },
        {
            "type": "other",
            "url": "https://www.doctrine-project.org/sponsorship.html"
        }
    ]
}

可选。

以下所有内容都接受一个对象，该对象通过版本约束将包名称映射到包的版本。在此处阅读有关版本的更多信息：这里。

示例

{
    "require": {
        "monolog/monolog": "1.0.*"
    }
}

所有链接都是可选字段。

require 和 require-dev 还支持稳定性标志（仅限根目录）。它们采用 “约束@稳定性标志” 的形式。这些允许您进一步限制或扩展包的稳定性，超出 minimum-stability 设置的范围。您可以将它们应用于约束，或者如果您希望允许例如依赖项的不稳定包，则可以将它们应用于空约束。

示例

{
    "require": {
        "monolog/monolog": "1.0.*@beta",
        "acme/foo": "@dev"
    }
}

如果您依赖项的某个依赖项依赖于不稳定包，则需要显式要求它以及相应的稳定性标志。

示例

假设 doctrine/doctrine-fixtures-bundle 依赖于 "doctrine/data-fixtures": "dev-master"，那么在根 composer.json 中，您需要添加下面的第二行，以允许 doctrine/data-fixtures 包的开发版

{
    "require": {
        "doctrine/doctrine-fixtures-bundle": "dev-master",
        "doctrine/data-fixtures": "@dev"
    }
}

require 和 require-dev 还支持为开发版本指定显式引用（例如提交），以确保即使在运行更新时，它们也会锁定到给定状态。这些只有在您显式地需要开发版本并在引用后面追加 #<ref> 时才有效。这也是一个 根目录专用 功能，在依赖项中会被忽略。

示例

{
    "require": {
        "monolog/monolog": "dev-master#2eb0c0978d290a1c45346a1955188929cb4e5db7",
        "acme/foo": "1.0.x-dev#abc123"
    }
}

注意：此功能存在严重的技术限制，因为 composer.json 元数据仍然会从您在哈希之前指定的 分支名称 中读取。因此，您应该只在开发过程中将其用作临时解决方案，以解决瞬态问题，直到您可以切换到标记版本为止。Composer 团队并不积极支持此功能，也不会接受与之相关的错误报告。

还可以内联别名一个包约束，使其与它本来不会匹配的约束相匹配。有关更多信息，请 查看别名文章。

require 和 require-dev 还支持引用您的项目成功运行所需的特定 PHP 版本和 PHP 扩展。

示例

{
    "require": {
        "php": ">=7.4",
        "ext-mbstring": "*"
    }
}

注意：列出项目所需的 PHP 扩展很重要。并非所有 PHP 安装都相同：有些可能缺少您认为是标准的扩展（例如 ext-mysqli，它在 Fedora/CentOS 最小安装系统中默认不安装）。未能列出所需的 PHP 扩展可能会导致糟糕的用户体验：Composer 将安装您的包，没有任何错误，但它将在运行时失败。composer show --platform 命令列出了系统上所有可用的 PHP 扩展。您可以使用它来帮助您编译您使用和需要的扩展列表。或者，您可以使用第三方工具来分析您的项目以获取使用的扩展列表。

require#

此包所需的包映射。除非满足这些要求，否则不会安装该包。

require-dev (根目录专用)#

开发此包或运行测试等所需的包映射。根包的开发需求默认安装。install 或 update 都支持 --no-dev 选项，该选项阻止安装开发依赖项。

conflict#

与此包的此版本冲突的包映射。它们将不允许与您的包一起安装。

请注意，在 conflict 链接中指定范围（例如 <1.0 >=1.1）时，这将说明与小于 1.0 并且 等于或大于 1.1 的所有版本同时冲突，这可能不是您想要的。在这种情况下，您可能希望选择 <1.0 || >=1.1。

replace#

被此包替换的包映射。这允许您分叉一个包，将其发布到另一个名称下，并使用自己的版本号，而需要原始包的包仍然可以与您的分叉版本一起使用，因为它替换了原始包。

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

在使用 replace 完成上述子包目的时，建议谨慎。然后，您通常应该只使用 self.version 作为版本约束进行替换，以确保主包只替换该确切版本的子包，而不是任何其他版本，这将是不正确的。

provide#

此包提供的包映射。这对于实现通用接口非常有用。一个包可能依赖于一些虚拟包，例如 psr/log-implementation，任何实现此日志记录接口的库都将在 provide 中列出它。然后可以在 Packagist.org 上找到实现者。

使用 provide 来提供实际包的名称而不是虚拟包的名称，意味着该包的代码也被提供，在这种情况下，replace 通常是一个更好的选择。为提供接口并依赖其他包来提供实现的包（例如 PSR 接口）的常见约定是为对应于接口包的虚拟包的名称使用 -implementation 后缀。

suggest#

可以增强此包或与之良好协作的建议包。这些只是信息性的，在安装包后显示，以便向您的用户提示他们可以添加更多包，即使它们不是严格要求的。

格式与上面的包链接类似，除了值是自由文本而不是版本约束。

示例

{
    "suggest": {
        "monolog/monolog": "Allows more advanced logging of the application flow",
        "ext-xml": "Needed to support XML format in class Foo"
    }
}

autoload#

PHP 自动加载器的自动加载映射。

PSR-4 和 PSR-0 自动加载、classmap 生成和 files 包含都受支持。

PSR-4 是推荐的方式，因为它提供了更易于使用的功能（在添加类时无需重新生成自动加载器）。

PSR-4#

在 psr-4 键下，您定义了从命名空间到路径的映射，相对于包根目录。当自动加载一个类（例如 Foo\\Bar\\Baz）时，一个指向 src/ 目录的命名空间前缀 Foo\\ 意味着自动加载器将在名为 src/Bar/Baz.php 的文件中查找，如果存在则包含它。请注意，与旧的 PSR-0 样式相比，前缀（Foo\\）**不会**出现在文件路径中。

命名空间前缀必须以 \\ 结尾，以避免类似前缀之间的冲突。例如，Foo 将匹配 FooBar 命名空间中的类，因此尾部反斜杠解决了这个问题：Foo\\ 和 FooBar\\ 是不同的。

PSR-4 引用在安装/更新期间全部组合成一个键 => 值数组，该数组可以在生成的 vendor/composer/autoload_psr4.php 文件中找到。

示例

{
    "autoload": {
        "psr-4": {
            "Monolog\\": "src/",
            "Vendor\\Namespace\\": ""
        }
    }
}

如果您需要在多个目录中搜索相同的词缀，您可以将它们指定为一个数组，如下所示

{
    "autoload": {
        "psr-4": { "Monolog\\": ["src/", "lib/"] }
    }
}

如果您想有一个任何命名空间都会被查找的回退目录，您可以使用一个空前缀，例如

{
    "autoload": {
        "psr-4": { "": "src/" }
    }
}

PSR-0#

在 psr-0 键下，您定义了从命名空间到路径的映射，相对于包根目录。请注意，这也支持 PEAR 样式的非命名空间约定。

请注意，命名空间声明应该以 \\ 结尾，以确保自动加载器完全响应。例如，Foo 将匹配 FooBar，因此尾部反斜杠解决了这个问题：Foo\\ 和 FooBar\\ 是不同的。

PSR-0 引用在安装/更新期间全部组合成一个键 => 值数组，该数组可以在生成的 vendor/composer/autoload_namespaces.php 文件中找到。

示例

{
    "autoload": {
        "psr-0": {
            "Monolog\\": "src/",
            "Vendor\\Namespace\\": "src/",
            "Vendor_Namespace_": "src/"
        }
    }
}

如果您需要在多个目录中搜索相同的词缀，您可以将它们指定为一个数组，如下所示

{
    "autoload": {
        "psr-0": { "Monolog\\": ["src/", "lib/"] }
    }
}

PSR-0 样式不仅限于命名空间声明，还可以指定到类级别。这对只有全局命名空间中的一个类的库很有用。例如，如果 php 源文件也位于包的根目录中，它可以像这样声明

{
    "autoload": {
        "psr-0": { "UniqueGlobalClass": "" }
    }
}

如果您想有一个任何命名空间都可以的回退目录，您可以使用一个空前缀，例如

{
    "autoload": {
        "psr-0": { "": "src/" }
    }
}

Classmap#

classmap 引用在安装/更新期间全部组合成一个键 => 值数组，该数组可以在生成的 vendor/composer/autoload_classmap.php 文件中找到。此映射是通过扫描给定目录/文件中的所有 .php 和 .inc 文件来构建的。

您可以使用 classmap 生成支持来定义所有不遵循 PSR-0/4 的库的自动加载。要配置它，您需要指定所有要搜索类的目录或文件。

示例

{
    "autoload": {
        "classmap": ["src/", "lib/", "Something.php"]
    }
}

通配符（*）也在 classmap 路径中受支持，并扩展以匹配任何目录名称

示例

{
    "autoload": {
        "classmap": ["src/addons/*/lib/", "3rd-party/*", "Something.php"]
    }
}

Files#

如果您想在每次请求时显式地要求某些文件，那么您可以使用 files 自动加载机制。如果您的包包含无法由 PHP 自动加载的 PHP 函数，这将很有用。

示例

{
    "autoload": {
        "files": ["src/MyLibrary/functions.php"]
    }
}

文件自动加载规则在包含 vendor/autoload.php 时包含，紧随自动加载器注册之后。包含顺序取决于包依赖项，因此，如果包 A 依赖于 B，那么包 B 中的文件将首先包含，以确保包 B 已完全初始化并准备好使用，然后包含来自包 A 的文件。

如果两个包具有相同的依赖项数量或没有依赖项，则顺序按字母顺序排列。

根包中的文件总是最后加载，您无法使用文件自动加载来覆盖来自依赖项的函数。如果您想实现这一点，我们建议您在包含 Composer 的 vendor/autoload.php 之前包含您自己的函数。

从 classmap 中排除文件#

如果您想从 classmap 中排除某些文件或文件夹，您可以使用 exclude-from-classmap 属性。这可能对从实时环境中排除测试类很有用，例如，因为即使在构建优化后的自动加载器时，这些类也会从 classmap 中跳过。

classmap 生成器将忽略此处配置的路径中的所有文件。路径是从包根目录（即 composer.json 位置）开始的绝对路径，并支持 * 来匹配除斜杠之外的任何内容，以及 ** 来匹配任何内容。** 被隐式地添加到路径的末尾。

示例

{
    "autoload": {
        "exclude-from-classmap": ["/Tests/", "/test/", "/tests/"]
    }
}

优化自动加载器#

自动加载器对您的请求时间可能会有相当大的影响（在大框架中使用大量类时，每个请求 50-100 毫秒）。有关如何减少这种影响的更多信息，请参阅 优化自动加载器的文章。

autoload-dev (根目录专用)#

本节允许为开发目的定义自动加载规则。

运行测试套件所需的类不应包含在主自动加载规则中，以避免污染生产环境中的自动加载器，以及当其他人使用您的包作为依赖项时。

因此，最好依赖于为您的单元测试专门的路径，并在 autoload-dev 部分中添加它。

示例

{
    "autoload": {
        "psr-4": { "MyLibrary\\": "src/" }
    },
    "autoload-dev": {
        "psr-4": { "MyLibrary\\Tests\\": "tests/" }
    }
}

include-path#

已弃用：这仅用于支持遗留项目，所有新代码最好使用自动加载。因此，这是一个过时的做法，但该功能本身不太可能从 Composer 中消失。

应该追加到 PHP 的 include_path 的路径列表。

示例

{
    "include-path": ["lib/"]
}

可选。

target-dir#

已弃用：这仅用于支持遗留的 PSR-0 样式自动加载，所有新代码最好使用没有 target-dir 的 PSR-4，而使用 PSR-0 和 PHP 命名空间的项目应鼓励迁移到 PSR-4。

定义安装目标。

如果包根目录位于命名空间声明下方，则无法正确自动加载。target-dir 可以解决这个问题。

例如 Symfony。它的组件有单独的包。Yaml 组件位于 Symfony\Component\Yaml 下。包根目录是 Yaml 目录。为了使自动加载成为可能，我们需要确保它没有安装到 vendor/symfony/yaml 中，而是安装到 vendor/symfony/yaml/Symfony/Component/Yaml 中，这样自动加载器就可以从 vendor/symfony/yaml 中加载它。

为此，autoload 和 target-dir 的定义如下：

{
    "autoload": {
        "psr-0": { "Symfony\\Component\\Yaml\\": "" }
    },
    "target-dir": "Symfony/Component/Yaml"
}

可选。

minimum-stability (root-only)#

这定义了根据稳定性过滤包的默认行为。默认为 stable，因此如果您依赖 dev 包，则应在您的文件中指定它，以避免意外情况。

将检查每个包的所有版本，并将稳定性低于 minimum-stability 设置的版本在解析项目依赖项时忽略。（请注意，您也可以使用 require 块中指定的版本约束中的稳定性标志，在每个包的基础上指定稳定性要求（有关更多详细信息，请参阅 包链接）。

可用的选项（按稳定性排序）为 dev、alpha、beta、RC 和 stable。

prefer-stable (root-only)#

启用此选项后，Composer 会在找到兼容的稳定包时，优先选择比不稳定包更稳定的包。如果您需要 dev 版本，或者只有 alpha 版本可用于某个包，那么只要 minimum-stability 允许，这些版本仍然会被选择。

使用 "prefer-stable": true 启用。

repositories (root-only)#

要使用的自定义包仓库。

默认情况下，Composer 只使用 packagist 仓库。通过指定仓库，您可以从其他地方获取包。

仓库不会递归解析。您只能将它们添加到主 composer.json 中。依赖项 composer.json 的仓库声明将被忽略。

支持以下仓库类型：

  • composer: Composer 仓库是一个通过网络（HTTP、FTP、SSH）提供的 packages.json 文件，其中包含包含 composer.json 对象列表的 composer.json 对象，以及其他 dist 和/或 source 信息。packages.json 文件是使用 PHP 流加载的。您可以使用 options 参数设置该流上的额外选项。
  • vcs: 版本控制系统仓库可以从 git、svn、fossil 和 hg 仓库中获取包。
  • package: 如果您依赖的项目完全不支持 Composer，您可以使用 package 仓库来定义该包。您基本上是在内联 composer.json 对象。

有关这些内容的更多信息，请参阅 仓库。

示例

{
    "repositories": [
        {
            "type": "composer",
            "url": "http://packages.example.com"
        },
        {
            "type": "composer",
            "url": "https://packages.example.com",
            "options": {
                "ssl": {
                    "verify_peer": "true"
                }
            }
        },
        {
            "type": "vcs",
            "url": "https://github.com/Seldaek/monolog"
        },
        {
            "type": "package",
            "package": {
                "name": "smarty/smarty",
                "version": "3.1.7",
                "dist": {
                    "url": "https://smarty.php.ac.cn/files/Smarty-3.1.7.zip",
                    "type": "zip"
                },
                "source": {
                    "url": "https://smarty-php.googlecode.com/svn/",
                    "type": "svn",
                    "reference": "tags/Smarty_3_1_7/distribution/"
                }
            }
        }
    ]
}

注意： 这里的顺序很重要。在查找包时，Composer 将从第一个仓库到最后一个仓库查找，并选择第一个匹配项。默认情况下，Packagist 会添加到最后，这意味着自定义仓库可以覆盖来自 Packagist 的包。

也可以使用 JSON 对象表示法。但是，JSON 键/值对被认为是无序的，因此无法保证一致的行为。

{
    "repositories": {
        "foo": {
            "type": "composer",
            "url": "http://packages.foo.com"
        }
    }
}

config (root-only)#

一组配置选项。它只用于项目。有关每个选项的描述，请参阅 配置。

scripts (root-only)#

Composer 允许您通过使用脚本将自己连接到安装过程的各个部分。

有关事件详细信息和示例，请参阅 脚本。

extra#

由 scripts 使用的任意额外数据。

它可以是几乎任何东西。要在脚本事件处理程序中访问它，您可以执行以下操作

$extra = $event->getComposer()->getPackage()->getExtra();

可选。

bin#

一组应被视为二进制文件并被提供到 bin-dir（来自配置）中的文件。

有关更多详细信息，请参阅 供应商二进制文件。

可选。

archive#

一组用于创建包存档的选项。

支持以下选项：

  • name: 允许配置存档的基名。默认情况下（如果未配置，并且未将 --file 作为命令行参数传递），将使用 preg_replace('#[^a-z0-9-_]#i', '-', name)。

示例

{
    "name": "org/strangeName",
    "archive": {
        "name": "Strange_name"
    }
}
  • exclude: 允许配置要排除的路径模式列表。模式语法与 .gitignore 文件匹配。开头的感叹号 (!) 将导致任何匹配的文件被包含在内，即使先前的模式排除了它们。开头的斜杠只会匹配项目相对路径的开头。星号不会扩展到目录分隔符。

示例

{
    "archive": {
        "exclude": ["/foo/bar", "baz", "/*.test", "!/foo/bar/baz"]
    }
}

此示例将包含 /dir/foo/bar/file、/foo/bar/baz、/file.php、/foo/my.test，但它将排除 /foo/bar/any、/foo/baz 和 /my.test。

可选。

abandoned#

指示此包是否已被放弃。

它可以是布尔值或指向推荐替代方案的包名称/URL。

示例

使用 "abandoned": true 来表示此包已被放弃。使用 "abandoned": "monolog/monolog" 来表示此包已被放弃，并且推荐的替代方案是 monolog/monolog。

默认为 false。

可选。

_comment#

用作存储注释的地方的顶级键（它可以是字符串或字符串数组）。

{
    "_comment": [
        "The package foo/bar was required for business logic",
        "Remove package foo/baz when removing foo/bar"
    ]
}

默认为空。

可选。

non-feature-branches#

一个分支名称的正则表达式模式列表，这些模式是非数字的（例如“latest”或其他），不会被视为功能分支。这是一个字符串数组。

如果您有非数字分支名称，例如“latest”、“current”、“latest-stable”或其他，看起来不像版本号，那么 Composer 会将此类分支视为功能分支。这意味着它会搜索父分支，这些分支看起来像版本或以特殊分支（如 master）结束，并且根包版本号将成为父分支的版本，或者至少是 master 或其他。

要将非数字命名的分支处理为版本，而不是搜索具有有效版本或特殊分支名称（如 master）的父分支，您可以为应处理为 dev 版本分支的分支名称设置模式。

当您的依赖项使用“self.version”时，这非常有用，这样就不会安装 dev-master，而是安装相同的分支（在示例中：latest-testing）。

一个示例

如果您有一个测试分支，在测试阶段得到大量维护并部署到您的暂存环境，通常 composer show -s 会为您提供 versions : * dev-master。

如果您将 latest-.* 配置为非功能分支的模式，如下所示

{
    "non-feature-branches": ["latest-.*"]
}

那么 composer show -s 将为您提供 versions : * dev-latest-testing。

可选。

← 命令行界面 | 仓库 →

发现错别字？文档中有什么错误？ 分支并编辑 它！