composer.json 架构 #

本章将解释 composer.json 。

JSON 架构 #

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

根包 #

根包是由 composer.json 根源 你的项目。这是主要的 composer.json 定义你的项目 要求。

某些字段仅在根包上下文中适用。以下是 这是 config 字段。只有根包可以定义配置。 依赖项的配置将被忽略。这使得 config 场地 root-only 。

笔记： 一个包可以是根包，也可以不是，这取决于上下文。 例如，如果你的项目依赖于 monolog 图书馆，你的项目 是根包。但是，如果你克隆 monolog 来自 GitHub，以便 修复其中的一个错误，然后 monolog 是根包。

特性 #

姓名 #

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

  • 独白/独白
  • igorw/事件源

名称必须小写，并由以 - , . 或者 _ 。 完整名称应该匹配 ^[a-z0-9]([_.-]?[a-z0-9]+)*/[a-z0-9](([_.]|-{1,2})?[a-z0-9]+)*$ 。

这 name 已发布的包（库）需要属性。

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

描述 #

软件包的简短描述。通常只有一行。

已发布的包（库）是必需的。

版本 #

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

必须遵循以下格式 X.Y.Z 或者 vX.Y.Z 带有可选后缀 的 -dev , -patch （ -p ), -alpha （ -a ), -beta （ -b ） 或者 -RC 。 patch、alpha、beta 和 RC 后缀后面也可以跟数字。

例子：

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

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

笔记： Packagist 使用 VCS 存储库，因此上述声明非常 对于 Packagist 来说也是如此。自己指定版本将 很可能最终会由于人为错误而导致某个时候出现问题。

类型 #

包的类型。默认为 library 。

软件包类型用于自定义安装逻辑。如果您有软件包 需要一些特殊逻辑，你可以定义一个自定义类型。这可以是 symfony-bundle ， A wordpress-plugin 或 typo3-cms-extension . 这些类型 都将针对特定的项目，他们需要提供 安装程序能够安装该类型的包。

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

  • 图书馆： 这是默认设置。它将文件复制到 vendor 。
  • 项目： 这表示一个项目，而不是一个库。例如 应用程序外壳，例如 Symfony 标准版 , CMS 类似 Silverstripe 安装程序 或以软件包形式分发的完整应用程序。例如，这可以 供 IDE 使用，提供创建时要初始化的项目列表 一个新的工作区。
  • 元包： 包含要求并将触发的空包 他们的安装，但不包含任何文件，也不会写入任何内容 文件系统。因此，它不需要 dist 或源密钥来 可安装。
  • 作曲家插件： 类型的包 composer-plugin 可能会提供 安装程序，用于具有自定义类型的其他软件包。更多信息请阅读 专题文章 。
  • php-ext 和 php-ext-zend ：这些名称是为 PHP 扩展保留的 用 C 编写的包。不要将这些类型用于用 在 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.md 。

这主要对不在 GitHub 上的包有用，因为对于 GitHub 包，Packagist.org 将使用 readme API 来获取 GitHub 检测到的包。

选修的。

时间 #

版本的发布日期。

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

选修的。

执照 #

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

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

  • Apache-2.0
  • BSD-2-条款
  • BSD-3-条款
  • BSD-4-条款
  • GPL-2.0-only / GPL-2.0-或更高版本
  • GPL-3.0-only / GPL-3.0-或更高版本
  • LGPL-2.1-only / LGPL-2.1-或更高版本
  • LGPL-3.0-only / 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)"
}

类似地，当需要应用多个许可证（“连接许可证”）时，它们应该用“and”分隔并用括号括起来。

作者 #

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

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

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

举个例子：

{
    "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"
        }
    ]
}

可选，但强烈推荐。

支持 #

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

支持信息包括以下内容：

  • 电子邮件： 用于支持的电子邮件地址。
  • 问题： 问题跟踪器的 URL。
  • 论坛： 论坛的 URL。
  • 星期： 维基百科的 URL。
  • IRCS： IRC 支持频道，如 irc://server/channel。
  • 来源： 浏览或下载源的 URL。
  • 文档： 文档的 URL。
  • RSS： RSS 源的 URL。
  • 聊天： 聊天频道的 URL。
  • 安全： 漏洞披露政策 (VDP) 的 URL。

举个例子：

{
    "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 另外支持 稳定旗帜 （ 仅限 root ）。 它们的形式为“ 约束 @ 稳定旗 “。 这些允许您进一步限制或扩展包的稳定性 范围 最小稳定性 设置。您可以应用 将它们添加到约束，或者将它们应用到空的 约束 如果你想 例如，允许依赖项的不稳定包。

例子：

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

如果您的某个依赖项依赖于不稳定包，那么您也需要明确地需要它，以及其足够的稳定性标志。

例子：

假设 doctrine/doctrine-fixtures-bundle 需要 "doctrine/data-fixtures": "dev-master" 然后在根 composer.json 中你需要添加下面的第二行以允许 dev 发布的 doctrine/data-fixtures 包裹 ：

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

require 和 require-dev 另外支持明确的引用（即 提交）以确保它们被锁定在给定状态，即使 当您运行更新时。这些仅在您明确要求开发版本时才有效 并附加参考 #<ref> .这也是 仅限 root 功能，并将被忽略 依赖项。

例子：

{
    "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 扩展 您的系统。您可以使用它来帮助您编译您所需的扩展列表 使用和要求。或者，您可以使用第三方工具来分析 您的项目所使用的扩展列表。

要求 #

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

需要开发 （ 仅限 root ） #

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

冲突 #

此软件包版本与以下软件包不兼容：这些软件包将不允许与您的软件包一起安装。

请注意，在指定范围时 <1.0 >=1.1 在一个 conflict 关联， 这将表明与所有低于 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 参考全部合并为一个 key => value 数组，可以在生成的文件中找到 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 在安装/更新过程中，所有引用都合并为一个 key => value 数组，可以在生成的文件中找到 vendor/composer/autoload_classmap.php 。此地图是通过扫描 总共有 100 个班级 .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 中的文件，以确保包 B 完全 当包含包 A 中的文件时，已初始化并准备使用。

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

根包中的文件始终最后加载，并且您不能使用文件自动加载 自己重写依赖项中的函数。如果你想实现这一点，我们建议 你包含自己的功能 前 包括作曲家的 vendor/autoload.php 。

从类图中排除文件 #

如果要从类图中排除某些文件或文件夹，可以使用 exclude-from-classmap 财产。 例如，这可能有助于排除实时环境中的测试类，因为这些测试类将被跳过 即使在构建优化的自动加载器时，也可以从类图中获取。

类图生成器将忽略此处配置的路径中的所有文件。路径是绝对路径，来自包 根目录（即 composer.json 位置），并支持 * 匹配除斜线以外的任何字符，并且 ** 到 匹配任何东西。 ** 被隐式添加到路径的末尾。

例子：

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

优化自动加载器 #

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

自动加载设备 （ 仅限 root ） #

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

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

因此，依靠专用路径进行单元测试并将其添加到 autoload-dev 部分中是一个好主意。

例子：

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

包含路径 #

已弃用 ：这只是为了支持遗留项目和所有新代码 最好使用自动加载。因此，这是一种不推荐的做法，但 功能本身不太可能从 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"
}

选修的。

最小稳定性 （ 仅限 root ） #

这定义了按稳定性筛选包的默认行为。这 默认为 stable ，所以如果你依赖 dev 包，你应该指定 将其保存在您的文件中以避免意外。

每个软件包的所有版本都会检查其稳定性，稳定性较低的版本 比 minimum-stability 解析时将忽略设置 您的项目依赖项。（请注意，您还可以指定稳定性要求 在每个软件包的基础上，使用版本约束中的稳定性标志 在 require 阻止（参见 软件包链接 了解更多详细信息）。

可用选项（按稳定性顺序）包括 dev , alpha , beta , RC , 和 stable 。

偏好稳定 （ 仅限 root ） #

启用此功能后，在可以找到兼容的稳定软件包时，Composer 将优先选择更稳定的软件包，而不是不稳定的软件包。如果您需要开发版本或软件包只有 alpha 版本，则仍会选择这些版本，前提是最低稳定性允许。

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

存储库 （ 仅限 root ） #

要使用的自定义包存储库。

Composer 默认只使用 packagist 仓库。通过指定仓库，你可以从其他地方获取软件包。

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

支持以下存储库类型：

  • 作曲家： Composer 存储库是 packages.json 文件已送达 通过网络（HTTP、FTP、SSH），其中包含 composer.json 带有附加对象的对象 dist 和/或 source 信息。 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"
        }
    }
}

它将被“物业”这个名称所取代。

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

配置 （ 仅限 root ） #

一组配置选项。它仅用于项目。请参阅 配置 了解每个单独选项的描述。

脚本 （ 仅限 root ） #

Composer 允许您通过使用脚本来参与安装过程的各个部分。

看 脚本 了解活动详情和示例。

额外的 #

供以下人员使用的任意额外数据 scripts 。

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

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

选修的。

垃圾桶 #

一组应被视为二进制文件并可供使用的文件 进入 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。

选修的。

_评论 #

顶级键用作存储注释的位置（可以是字符串或字符串数​​组）。

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

默认为空。

选修的。

非特性分支 #

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

如果您有非数字的分支名称，例如“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 。

选修的。

← 命令行界面 | 存储库 →

发现拼写错误？此文档有问题？ 分叉并编辑 它！