composer.json 模式

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

JSON 模式

我们有一个JSON 模式，它记录了格式，还可用于验证您的composer.json。实际上，validate命令就使用了该模式。您可以在以下位置找到它：https://getcomposer.org/schema.json

根包

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

某些字段仅在根包上下文中适用。其中一个例子是config字段。只有根包可以定义配置。依赖项的配置会被忽略。这使得config字段成为root-only的字段。

注意： 一个包可以是根包，也可以不是，这取决于具体语境。例如，如果你的项目依赖于monolog库，那么你的项目就是根包。但是，如果你从GitHub上克隆monolog是为了修复其中的一个bug，那么monolog就是根包。

属性

名称

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

• 独白/独白
• 伊戈尔·w/事件源

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

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

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

description

对包的简短描述。通常为一行。

已发布的包（库）需要。

版本

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

这必须遵循X.Y.Z或vX.Y.Z的格式，可选择添加后缀-dev、-patch（-p）、-alpha（-a）、-beta（-b）或-RC。补丁、阿尔法、贝塔和RC后缀后还可以跟一个数字。

示例：

• 1.0.0-dev
• 1.0.0-alpha3
• 1.0.0-beta2
• 1.0.0-RC5
• v2.0.4-p1

如果包仓库可以从某处（例如版本控制系统仓库中的版本控制系统标签名称）推断出版本，则此字段为可选。在这种情况下，也建议省略该字段。

**注意：**Packagist 使用版本控制系统（VCS）仓库，因此上述声明对于 Packagist 来说也非常适用。自行指定版本很可能会因人为错误在某些时候产生问题。

类型

包的类型。默认为library。

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

Composer 开箱即支持四种类型：

• **库：**这是默认类型。它会将文件复制到vendor目录。
• 项目： 这表示一个项目而非库。例如，像Symfony标准版这样的应用程序框架、像Silverstripe安装程序这样的内容管理系统，或者作为包分发的成熟应用程序。例如，这可被集成开发环境（IDEs）用于在创建新工作区时提供可初始化的项目列表。
• **元包：**一种空包，包含依赖项并会触发它们的安装，但本身不包含任何文件，也不会向文件系统写入任何内容。因此，它不需要dist或source键即可安装。
• **composer插件：**类型为composer-plugin的包可以为其他具有自定义类型的包提供安装程序。在专门的文章中了解更多信息。
• php-ext和php-ext-zend：这些名称是为用C语言编写的PHP扩展包保留的。不要将这些类型用于用PHP编写的包。

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

关键词

与该包相关的一系列关键词。这些关键词可用于搜索和筛选。

示例：

• 日志记录
• 事件
• 数据库
• redis
• 模板化

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

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

可选的。

主页

项目网站的URL。

可选的。

自述文件

README文档的相对路径。默认为README.html。

这主要对不在GitHub上的包有用，因为对于GitHub上的包，Packagist.org会使用自述文件API来获取GitHub检测到的那个。

可选的。

时间

版本的发布日期。

必须采用UTC时区的YYYY-MM-DD或YYYY-MM-DD HH:MM:SS格式。

可选的。

许可证

包的许可证。它可以是一个字符串，也可以是一个字符串数组。

最常见许可证的推荐表示法如下（按字母顺序排列）：

• Apache-2.0
• BSD-2-Clause
• BSD-3-Clause
• BSD-4-条款
• GPL-2.0-仅 / GPL-2.0-或更高版本
• GPL-3.0-仅 / GPL-3.0-或更高版本
• LGPL-2.1-仅 / LGPL-2.1-或更高版本
• LGPL-3.0-仅 / LGPL-3.0-或更高版本
• 与

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

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

一个示例：

{
    "license": "MIT"
}

对于一个软件包，当存在许可证选择（“选择性许可证”）时，可以将多个许可证指定为一个数组。

析取许可的示例：

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

或者，它们可以用“或”分隔并放在括号中；

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

同样，当需要应用多个许可证（“联合许可证”）时，它们应以“和”分隔并放在括号中。

作者

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

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

• **姓名：**作者的姓名。通常是他们的真实姓名。
• **电子邮件：**作者的电子邮件地址。
• **主页：**作者网站的网址。
• **角色：**作者在项目中的角色（例如，开发者或翻译者）

示例：

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

可选，但强烈推荐。

支持

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

支持信息包括以下内容：

• 电子邮件： 用于获取支持的电子邮件地址。
• **问题：**问题跟踪器的网址。
• **论坛：**论坛的网址。
• **维基：**维基的网址。
• irc： 用于获取支持的IRC频道，格式为irc://server/channel。
• **来源：**用于浏览或下载来源的URL。
• **文档：**指向文档的URL。
• rss: RSS 订阅源的 URL。
• chat: 聊天频道的URL。
• **安全：**漏洞披露政策（VDP）的网址。

示例：

{
    "support": {
        "email": "support@example.org",
        "irc": "irc://irc.freenode.org/composer"
    }
}

可选的。

资金

一份为软件包作者提供资金以支持其维护和开发新功能的URL列表。

每个条目包含以下内容

• **类型：**资助的类型，或可提供资助的平台，例如patreon、opencollective、tidelift或github。
• 网址： 指向包含详细信息和为该软件包提供资金支持方式的网站的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 还额外支持 稳定性标记（仅限根目录</b3）。它们采用“约束@稳定性标记”的形式。这些标记允许你在 minimum-stability</b6 设置的范围之外，进一步限制或扩展某个包的稳定性。例如，你可以将它们应用于某个约束，或者如果想要允许某个依赖项的不稳定包，也可以将它们应用于空的 约束。

示例：

{
    "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 选项，该选项可阻止安装开发依赖项。

冲突

与本版本软件包不兼容的软件包地图。它们不允许与您的软件包一起安装。

请注意，在<1.0 >=1.1之类的范围时，这将表示与所有同时小于1.0且等于或高于1.1的版本存在冲突，这可能并非你想要的结果。在这种情况下，你可能希望使用<1.0 || >=1.1。

替换

由本包替代的包的映射。这使您可以分叉一个包，以不同的名称及其自己的版本号发布它，而需要原始包的包仍然可以与您的分叉包一起使用，因为它替代了原始包。

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

在出于上述解释的子包目的使用replace时，需要谨慎。此时，你通常应该仅使用self.version作为版本约束进行替换，以确保主包仅替换该确切版本的子包，而不是其他任何版本，否则会出现错误。

提供

此包所提供的包的映射。这对于常见接口的实现来说大多很有用。一个包可能依赖于某些虚拟包，例如psr/log-implementation，任何实现此日志器接口的库都会在provide中列出它。然后可以在Packagist.org上找到实现者。

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

建议

建议的软件包可以增强此软件包的功能或与其良好协作。这些信息性内容会在该软件包安装后显示，旨在提示您的用户可以添加更多软件包，尽管它们并非严格必需。

格式与上面的包链接类似，不同之处在于这些值是自由文本，而非版本约束。

示例：

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

自动加载

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

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

PSR-4 是推荐的方式，因为它使用起来更便捷（添加类时无需重新生成自动加载器）。

PSR-4

在psr-4键下，你可以定义从命名空间到路径的映射，该路径相对于包的根目录。当自动加载像Foo\\Bar\\Baz这样的类时，如果命名空间前缀Foo\\指向目录src/，这意味着自动加载器会查找名为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引用会被合并成一个单一的键值数组，该数组可在生成的文件vendor/composer/autoload_classmap.php中找到。此映射是通过扫描指定目录/文件中的所有.php和.inc文件中的类来构建的。

你可以使用类映射生成支持，为所有不遵循PSR-0/4的库定义自动加载。要配置此功能，你需要指定所有用于搜索类的目录或文件。

示例：

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

类映射路径中也支持通配符（*），它会展开以匹配任何目录名称：

示例：

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

文件

如果你希望在每次请求时都明确加载某些文件，可以使用files自动加载机制。如果你的包中包含PHP无法自动加载的PHP函数，这会非常有用。

示例：

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

只要包含vendor/autoload.php，文件自动加载规则就会被包含进来，且是在自动加载器注册之后立即进行。包含的顺序取决于包的依赖关系，因此如果包A依赖于包B，那么包B中的文件会先被包含，以确保在包含包A中的文件时，包B已完全初始化并可以使用。

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

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

从类映射中排除文件

如果您想从类映射中排除某些文件或文件夹，可以使用exclude-from-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/"]
}

可选的。

目标目录

已弃用：仅为支持旧版PSR-0风格的自动加载而保留，所有新代码应优先使用不带target-dir的PSR-4，且鼓励使用带PHP命名空间的PSR-0的项目迁移至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（仅限根目录）

这定义了按稳定性筛选包的默认行为。默认值为stable，因此如果您依赖dev包，应该在文件中指定它，以避免意外情况。

每个包的所有版本都会经过稳定性检查，在解析您的项目依赖时，那些稳定性低于minimum-stability设置的版本将被忽略。（请注意，您还可以在require块中指定的版本约束中使用稳定性标志，按包指定稳定性要求（详情请参见包链接）。

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

prefer-stable（仅限根目录）

启用此功能后，当可以找到兼容的稳定包时，Composer会优先选择更稳定的包。如果您需要开发版本，或者某个包只有alpha版本可用，只要最低稳定性允许，这些版本仍会被选中。

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

仓库（仅根目录）

要使用的自定义包仓库。

默认情况下，Composer仅使用packagist代码库。通过指定代码库，你可以从其他地方获取包。

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

支持以下仓库类型：

• **作曲家：**Composer 仓库是一个通过网络（HTTP、FTP、SSH）提供的packages.json文件，其中包含一系列带有额外dist和/或source信息的composer.json对象。packages.json文件通过 PHP 流加载。你可以使用options参数在该流上设置额外选项。
• **版本控制系统：**版本控制系统仓库可以从git、svn、fossil和hg仓库获取包。
• **包：**如果您依赖的项目完全不支持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://www.smarty.net/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 会被添加到最后，这意味着自定义仓库可以覆盖其中的包。

也可以使用JSON对象表示法。但是，JSON键/值对被视为无序的，因此无法保证一致的行为，这种方式已被弃用。

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

它将被name属性取代

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

config（仅根目录）

一组配置选项。它仅用于项目。有关各个选项的说明，请参见配置。

脚本（仅限根目录）

Composer 允许你通过使用脚本挂钩到安装过程的各个部分。

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

额外信息

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

这几乎可以是任何内容。要从脚本事件处理器中访问它，你可以这样做：

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

可选的。

bin

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

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

可选的。

归档

一组用于创建包归档文件的选项。

支持以下选项：

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

示例：

{
    "name": "org/strangeName",
    "archive": {
        "name": "Strange_name"
    }
}

• **排除：**允许配置排除路径的模式列表。该模式语法与.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。

可选的。

废弃 指示此包是否已被废弃。 它可以是布尔值，也可以是指向推荐替代项的包名称/URL。 使用”abandoned”: true表示此包已被废弃。使用”abandoned”: “monolog/monolog”表示此包已被废弃，且推荐的替代项是monolog/monolog。 默认值为false。

指示此包是否已被废弃。

它可以是布尔值，也可以是指向推荐替代方案的包名/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"
    ]
}

默认为空。

可选的。

非功能分支

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

如果你有非数字的分支名称，例如“latest”“current”“latest-stable”之类的，看起来不像版本号，那么Composer会将这类分支当作功能分支来处理。这意味着它会搜索看起来像版本号的父分支，或者以特殊分支（如master）结尾的父分支，而根包版本号会变成父分支的版本号，或者至少是master之类的版本号。

若要将非数字命名的分支作为版本来处理，而非搜索带有有效版本或特殊分支名称（如master）的父分支，您可以为应作为开发版本分支处理的分支名称设置模式。

当您的依赖项使用“self.version”时，这确实很有帮助，这样安装的就不是dev-master，而是同一个分支（在示例中是latest-testing）。

示例：

如果你有一个测试分支，该分支在测试阶段得到大量维护并部署到你的预发布环境，通常composer show -s会显示versions : * dev-master。

如果您像这样将latest-.*配置为非功能分支的模式：

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

然后，composer show -s 会显示 versions : * dev-latest-testing。

可选的。