鍍金池/ 教程/ PHP/ composer.json 架構(gòu)
簡(jiǎn)介 中文文檔
腳本
命令行
資源庫(kù)
庫(kù)(資源包)
Composer PHP依賴管理的新時(shí)代
插件
別名
自定義安裝程序
二進(jìn)制供應(yīng)庫(kù)和 <code>vendor/bin</code> 目錄
如何為我的框架自定義一個(gè)資源包安裝目錄?
composer.json 架構(gòu)
我應(yīng)該提交 vendor 目錄中的依賴包嗎?
為什么 Composer 不遞歸加載儲(chǔ)存庫(kù)?
基本用法
為什么說(shuō)“比較符”和“通配符”相結(jié)合的版本約束是壞主意?

composer.json 架構(gòu)

本章將解釋所有在 composer.json 中可用的字段。

JSON schema

我們有一個(gè) JSON schema 格式化文檔,它也可以被用來(lái)驗(yàn)證你的 composer.json 文件。事實(shí)上,它已經(jīng)被 validate 命令所使用。 你可以在這里找到它: res/composer-schema.json.

Root 包

“root 包”是指由 composer.json 定義的在你項(xiàng)目根目錄的包。這是 composer.json 定義你項(xiàng)目所需的主要條件。(簡(jiǎn)單的說(shuō),你自己的項(xiàng)目就是一個(gè) root 包)

某些字段僅適用于“root 包”上下文。 config 字段就是其中一個(gè)例子。只有“root 包”可以定義。在依賴包中定義的 config 字段將被忽略,這使得 config 字段只有“root 包”可用(root-only)。

如果你克隆了其中的一個(gè)依賴包,直接在其上開(kāi)始工作,那么它就變成了“root 包”。與作為他人的依賴包時(shí)使用相同的 composer.json 文件,但上下文發(fā)生了變化。

注意: 一個(gè)資源包是不是“root 包”,取決于它的上下文。 例:如果你的項(xiàng)目依賴 monolog 庫(kù),那么你的項(xiàng)目就是“root 包”。 但是,如果你從 GitHub 上克隆了 monolog 為它修復(fù) bug, 那么此時(shí) monolog 就是“root 包”。

屬性

包名 name

包的名稱,它包括供應(yīng)商名稱和項(xiàng)目名稱,使用 / 分隔。

例:

  • monolog/monolog
  • igorw/event-source

對(duì)于需要發(fā)布的包(庫(kù)),這是必須填寫的。

描述 description

一個(gè)包的簡(jiǎn)短描述。通常這個(gè)最長(zhǎng)只有一行。

對(duì)于需要發(fā)布的包(庫(kù)),這是必須填寫的。

版本 version

version 不是必須的,并且建議忽略(見(jiàn)下文)。

它應(yīng)該符合 'X.Y.Z' 或者 'vX.Y.Z' 的形式, -dev、-patch、-alpha、-beta-RC 這些后綴是可選的。在后綴之后也可以再跟上一個(gè)數(shù)字。

例:

  • 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

通常,我們能夠從 VCS (git, svn, hg) 的信息推斷出包的版本號(hào),在這種情況下,我們建議忽略 version

注意: Packagist 使用 VCS 倉(cāng)庫(kù), 因此 version 定義的版本號(hào)必須是真實(shí)準(zhǔn)確的。 自己手動(dòng)指定的 version,最終有可能在某個(gè)時(shí)候因?yàn)槿藶殄e(cuò)誤造成問(wèn)題。

安裝類型 type

包的安裝類型,默認(rèn)為 library

包的安裝類型,用來(lái)定義安裝邏輯。如果你有一個(gè)包需要一個(gè)特殊的邏輯,你可以設(shè)定一個(gè)自定義的類型。這可以是一個(gè) symfony-bundle,一個(gè) wordpress-plugin 或者一個(gè) typo3-module。這些類型都將是具體到某一個(gè)項(xiàng)目,而對(duì)應(yīng)的項(xiàng)目將要提供一種能夠安裝該類型包的安裝程序。

composer 原生支持以下4種類型:

  • library: 這是默認(rèn)類型,它會(huì)簡(jiǎn)單的將文件復(fù)制到 vendor 目錄。
  • project: 這表示當(dāng)前包是一個(gè)項(xiàng)目,而不是一個(gè)庫(kù)。例:框架應(yīng)用程序 Symfony standard edition,內(nèi)容管理系統(tǒng) SilverStripe installer 或者完全成熟的分布式應(yīng)用程序。使用 IDE 創(chuàng)建一個(gè)新的工作區(qū)時(shí),這可以為其提供項(xiàng)目列表的初始化。
  • metapackage: 當(dāng)一個(gè)空的包,包含依賴并且需要觸發(fā)依賴的安裝,這將不會(huì)對(duì)系統(tǒng)寫入額外的文件。因此這種安裝類型并不需要一個(gè) dist 或 source。
  • composer-plugin: 一個(gè)安裝類型為 composer-plugin 的包,它有一個(gè)自定義安裝類型,可以為其它包提供一個(gè) installler。詳細(xì)請(qǐng)查看 自定義安裝類型。

僅在你需要一個(gè)自定義的安裝邏輯時(shí)才使用它。建議忽略這個(gè)屬性,采用默認(rèn)的 library。

關(guān)鍵字 keywords

該包相關(guān)的關(guān)鍵詞的數(shù)組。這些可用于搜索和過(guò)濾。

實(shí)例:

  • logging
  • events
  • database
  • redis
  • templating

可選。

項(xiàng)目主頁(yè) homepage

該項(xiàng)目網(wǎng)站的 URL 地址。

可選。

版本發(fā)布時(shí)間 time

版本發(fā)布時(shí)間。

必須符合 YYYY-MM-DDYYYY-MM-DD HH:MM:SS 格式。

可選。

許可協(xié)議 license

包的許可協(xié)議,它可以是一個(gè)字符串或者字符串?dāng)?shù)組。

最常見(jiàn)的許可協(xié)議的推薦寫法(按字母排序):

  • Apache-2.0
  • BSD-2-Clause
  • BSD-3-Clause
  • BSD-4-Clause
  • GPL-2.0
  • GPL-2.0+
  • GPL-3.0
  • GPL-3.0+
  • LGPL-2.1
  • LGPL-2.1+
  • LGPL-3.0
  • LGPL-3.0+
  • MIT

可選,但強(qiáng)烈建議提供此內(nèi)容。更多許可協(xié)議的標(biāo)識(shí)符請(qǐng)參見(jiàn) SPDX Open Source License Registry

對(duì)于閉源軟件,你必須使用 "proprietary" 協(xié)議標(biāo)識(shí)符。

一個(gè)例:

{
    "license": "MIT"
}

對(duì)于一個(gè)包,當(dāng)允許在多個(gè)許可協(xié)議間進(jìn)行選擇時(shí)("disjunctive license"),這些協(xié)議標(biāo)識(shí)符可以被指定為數(shù)組。

多協(xié)議的一個(gè)例:

{
    "license": [
       "LGPL-2.1",
       "GPL-3.0+"
    ]
}

另外它們也可以由 "or" 分隔,并寫在括號(hào)中:

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

同樣,當(dāng)有多個(gè)許可協(xié)議需要結(jié)合使用時(shí)("conjunctive license"),它們應(yīng)該被 "and" 分隔,并寫在括號(hào)中。

作者 authors

包的作者。這是一個(gè)對(duì)象數(shù)組。

這個(gè)對(duì)象必須包含以下屬性:

  • name: 作者的姓名,通常使用真名。
  • email: 作者的 email 地址。
  • homepage: 作者主頁(yè)的 URL 地址。
  • role: 該作者在此項(xiàng)目中擔(dān)任的角色(例:開(kāi)發(fā)人員 或 翻譯)。

一個(gè)實(shí)例:

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

可選,但強(qiáng)烈建議提供此內(nèi)容。

支持 support

獲取項(xiàng)目支持的向相關(guān)信息對(duì)象。

這個(gè)對(duì)象必須包含以下屬性:

  • email: 項(xiàng)目支持 email 地址。
  • issues: 跟蹤問(wèn)題的 URL 地址。
  • forum: 論壇地址。
  • wiki: Wiki 地址。
  • irc: IRC 聊天頻道地址,類似于 irc://server/channel。
  • source: 網(wǎng)址瀏覽或下載源。

一個(gè)實(shí)例:

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

可選。

Package links

下面提到的所有對(duì)象,都應(yīng)該是 包名 到 版本 的映射對(duì)象。

實(shí)例:

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

所有的這些都是可選的。

requirerequire-dev 還支持穩(wěn)定性標(biāo)簽(@,僅針對(duì)“root 包”)。這允許你在 minimum-stability設(shè)定的范圍外做進(jìn)一步的限制或擴(kuò)展。例:如果你想允許依賴一個(gè)不穩(wěn)定的包,你可以在一個(gè)包的版本約束后使用它,或者是一個(gè)空的版本約束內(nèi)使用它。

實(shí)例:

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

如果你的依賴之一,有對(duì)另一個(gè)不穩(wěn)定包的依賴,你最好在 require 中顯示的定義它,并帶上足夠詳細(xì)的穩(wěn)定性標(biāo)識(shí)。

實(shí)例:

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

requirerequire-dev 還支持對(duì) dev(開(kāi)發(fā))版本的明確引用(即:版本控制系統(tǒng)中的提交編號(hào) commit),以確保它們被鎖定到一個(gè)給定的狀態(tài),即使你運(yùn)行了更新命令。你只需要明確一個(gè)開(kāi)發(fā)版本號(hào),并帶上諸如 #<ref> 的標(biāo)識(shí)。

實(shí)例:

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

注意: 雖然這有時(shí)很方便,但不應(yīng)該長(zhǎng)期在你的包中使用,因?yàn)樗幸粋€(gè)技術(shù)上的限制。 composer.json 將仍然在哈希值之前指定的分支名稱讀取元數(shù)據(jù), 正因?yàn)槿绱耍谀承┣闆r下,它不會(huì)是一個(gè)實(shí)用的解決方法, 如果可能,你應(yīng)該總是嘗試切換到擁有標(biāo)簽的版本。

它也可以應(yīng)用于行內(nèi)別名,這樣它將匹配一個(gè)約束,否則不會(huì)。更多信息請(qǐng)參考 別名。

require

必須的軟件包列表,除非這些依賴被滿足,否則不會(huì)完成安裝。

require-dev (root-only)

這個(gè)列表是為開(kāi)發(fā)或測(cè)試等目的,額外列出的依賴?!皉oot 包”的 require-dev 默認(rèn)是會(huì)被安裝的。然而 installupdate 支持使用 --no-dev 參數(shù)來(lái)跳過(guò) require-dev 字段中列出的包。

conflict

此列表中的包與當(dāng)前包的這個(gè)版本沖突。它們將不允許同時(shí)被安裝。

請(qǐng)注意,在 conflict 中指定類似于 <1.0, >= 1.1 的版本范圍時(shí),這表示它與小于1.0 并且 同時(shí)大等于1.1的版本沖突,這很可能不是你想要的。在這種情況下你可能想要表達(dá)的是 <1.0 | >= 1.1 。

replace

這個(gè)列表中的包將被當(dāng)前包取代。這使你可以 fork 一個(gè)包,以不同的名稱和版本號(hào)發(fā)布,同時(shí)要求依賴于原包的其它包,在這之后依賴于你 fork 的這個(gè)包,因?yàn)樗〈嗽瓉?lái)的包。

這對(duì)于創(chuàng)建一個(gè)內(nèi)部包含子包的主包也非常的有用。例如 symfony/symfony 這個(gè)主包,包含了所有 Symfony 的組件,而這些組件又可以作為單獨(dú)的包進(jìn)行發(fā)布。如果你 require 了主包,那么它就會(huì)自動(dòng)完成其下各個(gè)組件的任務(wù),因?yàn)橹靼〈俗影?/p>

注意,在使用上述方法取代子包時(shí),通常你應(yīng)該只對(duì)子包使用 self.version 這一個(gè)版本約束,以確保主包僅替換掉子包的準(zhǔn)確版本,而不是任何其他版本。

provide

List of other packages that are provided by this package. This is mostly useful for common interfaces. A package could depend on some virtual logger package, any library that implements this logger interface would simply list it in provide.

suggest

建議安裝的包,它們?cè)鰪?qiáng)或能夠與當(dāng)前包良好的工作。這些只是信息,并顯示在依賴包安裝完成之后,給你的用戶一個(gè)建議,他們可以添加更多的包。

格式如下,版本約束變成了描述信息。

實(shí)例:

{
    "suggest": {
        "monolog/monolog": "Allows more advanced logging of the application flow"
    }
}

autoload

PHP autoloader 的自動(dòng)加載映射。

Currently PSR-0 autoloading, PSR-4 autoloading, classmap generation and files includes are supported. PSR-4 is the recommended way though since it offers greater ease of use (no need to regenerate the autoloader when you add classes).

PSR-4

Under the psr-4 key you define a mapping from namespaces to paths, relative to the package root. When autoloading a class like Foo\\Bar\\Baz a namespace prefix Foo\\ pointing to a directory src/ means that the autoloader will look for a file named src/Bar/Baz.php and include it if present. Note that as opposed to the older PSR-0 style, the prefix (Foo\\) is not present in the file path.

Namespace prefixes must end in \\ to avoid conflicts between similar prefixes. For example Foo would match classes in the FooBar namespace so the trailing backslashes solve the problem: Foo\\ and FooBar\\ are distinct.

The PSR-4 references are all combined, during install/update, into a single key => value array which may be found in the generated file vendor/composer/autoload_psr4.php.

Example:

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

If you need to search for a same prefix in multiple directories, you can specify them as an array as such:

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

If you want to have a fallback directory where any namespace will be looked for, you can use an empty prefix like:

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

PSR-0

psr-0 key 下你定義了一個(gè)命名空間到實(shí)際路徑的映射(相對(duì)于包的根目錄)。注意,這里同樣支持 PEAR-style 方式的約定(與命名空間不同,PEAR 類庫(kù)在類名上采用了下劃線分隔)。

請(qǐng)注意,命名空間的申明應(yīng)該以 \\ 結(jié)束,以確保 autoloader 能夠準(zhǔn)確響應(yīng)。例: Foo 將會(huì)與 FooBar 匹配,然而以反斜杠結(jié)束就可以解決這樣的問(wèn)題, Foo\\FooBar\\ 將會(huì)被區(qū)分開(kāi)來(lái)。

在 install/update 過(guò)程中,PSR-0 引用都將被結(jié)合為一個(gè)單一的鍵值對(duì)數(shù)組,存儲(chǔ)至 vendor/composer/autoload_namespaces.php 文件中。

實(shí)例:

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

如果你需要搜索多個(gè)目錄中一個(gè)相同的前綴,你可以將它們指定為一個(gè)數(shù)組,例:

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

PSR-0 方式并不僅限于申明命名空間,也可以是精確到類級(jí)別的指定。這對(duì)于只有一個(gè)類在全局命名空間的類庫(kù)是非常有用的(如果 php 源文件也位于包的根目錄)。例如,可以這樣申明:

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

如果你想設(shè)置一個(gè)目錄作為任何命名空間的備用目錄,你可以使用空的前綴,像這樣:

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

Classmap

classmap 引用的所有組合,都會(huì)在 install/update 過(guò)程中生成,并存儲(chǔ)到 vendor/composer/autoload_classmap.php 文件中。這個(gè) map 是經(jīng)過(guò)掃描指定目錄(同樣支持直接精確到文件)中所有的 .php.inc 文件里內(nèi)置的類而得到的。

你可以用 classmap 生成支持支持自定義加載的不遵循 PSR-0/4 規(guī)范的類庫(kù)。要配置它指向需要的目錄,以便能夠準(zhǔn)確搜索到類文件。

實(shí)例:

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

Files

如果你想要明確的指定,在每次請(qǐng)求時(shí)都要載入某些文件,那么你可以使用 'files' autoloading。通常作為函數(shù)庫(kù)的載入方式(而非類庫(kù))。

實(shí)例:

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

autoload-dev (root-only)

This section allows to define autoload rules for development purposes.

Classes needed to run the test suite should not be included in the main autoload rules to avoid polluting the autoloader in production and when other people use your package as a dependency.

Therefore, it is a good idea to rely on a dedicated path for your unit tests and to add it within the autoload-dev section.

Example:

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

include-path

不建議:這是目前唯一支持傳統(tǒng)項(xiàng)目的做法,所有新的代碼都建議使用自動(dòng)加載。 這是一個(gè)過(guò)時(shí)的做法,但 Composer 將仍然保留這個(gè)功能。

一個(gè)追加到 PHP include_path 中的列表。

實(shí)例:

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

可選。

target-dir

DEPRECATED: This is only present to support legacy PSR-0 style autoloading, and all new code should preferably use PSR-4 without target-dir and projects using PSR-0 with PHP namespaces are encouraged to migrate to PSR-4 instead.

定義當(dāng)前包安裝的目標(biāo)文件夾。

若某個(gè)包的根目錄,在它申明的命名空間之下,將不能正確的使用自動(dòng)加載。而 target-dir 解決了這個(gè)問(wèn)題。

Symfony 就是一個(gè)例子。它有一些獨(dú)立的包作為組件。Yaml 組件就放在 Symfony\Component\Yaml 目錄下,然而這個(gè)包的根目錄實(shí)際上是 Yaml。為了使自動(dòng)加載成為可能,我們需要確保它不會(huì)被安裝到 vendor/symfony/yaml,而是安裝到 vendor/symfony/yaml/Symfony/Component/Yaml,從而使 Symfony 定義的 autoloader 可以從 vendor/symfony/yaml 加載它。

要做到這一點(diǎn) autoloadtarget-dir 應(yīng)該定義如下:

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

可選。

minimum-stability (root-only)

這定義了通過(guò)穩(wěn)定性過(guò)濾包的默認(rèn)行為。默認(rèn)為 stable(穩(wěn)定)。因此如果你依賴于一個(gè) dev(開(kāi)發(fā))包,你應(yīng)該明確的進(jìn)行定義。

對(duì)每個(gè)包的所有版本都會(huì)進(jìn)行穩(wěn)定性檢查,而低于 minimum-stability 所設(shè)定的最低穩(wěn)定性的版本,將在解決依賴關(guān)系時(shí)被忽略。對(duì)于個(gè)別包的特殊穩(wěn)定性要求,可以在 requirerequire-dev 中設(shè)定(請(qǐng)參考 Package links)。

可用的穩(wěn)定性標(biāo)識(shí)(按字母排序):dev、alphabeta、RCstable。

prefer-stable (root-only)

當(dāng)此選項(xiàng)被激活時(shí),Composer 將優(yōu)先使用更穩(wěn)定的包版本。

使用 "prefer-stable": true 來(lái)激活它。

repositories (root-only)

使用自定義的包資源庫(kù)。

默認(rèn)情況下 composer 只使用 packagist 作為包的資源庫(kù)。通過(guò)指定資源庫(kù),你可以從其他地方獲取資源包。

Repositories 并不是遞歸調(diào)用的,只能在“Root包”的 composer.json 中定義。附屬包中的 composer.json 將被忽略。

支持以下類型的包資源庫(kù):

  • composer: 一個(gè) composer 類型的資源庫(kù),是一個(gè)簡(jiǎn)單的網(wǎng)絡(luò)服務(wù)器(HTTP、FTP、SSH)上的 packages.json 文件,它包含一個(gè) composer.json 對(duì)象的列表,有額外的 dist 和/或 source 信息。這個(gè) packages.json 文件是用一個(gè) PHP 流加載的。你可以使用 options 參數(shù)來(lái)設(shè)定額外的流信息。
  • vcs: 從 git、svn 和 hg 取得資源。
  • pear: 從 pear 獲取資源。
  • package: 如果你依賴于一個(gè)項(xiàng)目,它不提供任何對(duì) composer 的支持,你就可以使用這種類型。你基本上就只需要內(nèi)聯(lián)一個(gè) composer.json 對(duì)象。

更多相關(guān)內(nèi)容,請(qǐng)查看 資源庫(kù)

實(shí)例:

{
    "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": "pear",
            "url": "http://pear2.php.net"
        },
        {
            "type": "package",
            "package": {
                "name": "smarty/smarty",
                "version": "3.1.7",
                "dist": {
                    "url": "http://www.smarty.net/files/Smarty-3.1.7.zip",
                    "type": "zip"
                },
                "source": {
                    "url": "http://smarty-php.googlecode.com/svn/",
                    "type": "svn",
                    "reference": "tags/Smarty_3_1_7/distribution/"
                }
            }
        }
    ]
}

注意: 順序是非常重要的,當(dāng) Composer 查找資源包時(shí),它會(huì)按照順序進(jìn)行。默認(rèn)情況下 Packagist 是最后加入的,因此自定義設(shè)置將可以覆蓋 Packagist 上的包。

config (root-only)

下面的這一組選項(xiàng),僅用于項(xiàng)目。

支持以下選項(xiàng):

  • process-timeout: 默認(rèn)為 300。處理進(jìn)程結(jié)束時(shí)間,例如:git 克隆的時(shí)間。Composer 將放棄超時(shí)的任務(wù)。如果你的網(wǎng)絡(luò)緩慢或者正在使用一個(gè)巨大的包,你可能要將這個(gè)值設(shè)置的更高一些。
  • use-include-path: 默認(rèn)為 false。如果為 true,Composer autoloader 還將在 PHP include path 中繼續(xù)查找類文件。
  • preferred-install: 默認(rèn)為 auto。它的值可以是 source、distauto。這個(gè)選項(xiàng)允許你設(shè)置 Composer 的默認(rèn)安裝方法。
  • github-protocols: 默認(rèn)為 ["git", "https", "ssh"]。從 github.com 克隆時(shí)使用的協(xié)議優(yōu)先級(jí)清單,因此默認(rèn)情況下將優(yōu)先使用 git 協(xié)議進(jìn)行克隆。你可以重新排列它們的次序,例如,如果你的網(wǎng)絡(luò)有代理服務(wù)器或 git 協(xié)議的效率很低,你就可以提升 https 協(xié)議的優(yōu)先級(jí)。
  • github-oauth: 一個(gè)域名和 oauth keys 的列表。 例如:使用 {"github.com": "oauthtoken"} 作為此選項(xiàng)的值, 將使用 oauthtoken 來(lái)訪問(wèn) github 上的私人倉(cāng)庫(kù),并繞過(guò) low IP-based rate 的 API 限制。 關(guān)聯(lián)知識(shí)關(guān)于如何獲取 GitHub 的 OAuth token。
  • vendor-dir: 默認(rèn)為 vendor。通過(guò)設(shè)置你可以安裝依賴到不同的目錄。
  • bin-dir: 默認(rèn)為 vendor/bin。如果一個(gè)項(xiàng)目包含二進(jìn)制文件,它們將被連接到這個(gè)目錄。
  • cache-dir: unix 下默認(rèn)為 $home/cache,Windows 下默認(rèn)為 C:\Users\<user>\AppData\Local\Composer。用于存儲(chǔ) composer 所有的緩存文件。相關(guān)信息請(qǐng)查看 COMPOSER_HOME。
  • cache-files-dir: 默認(rèn)為 $cache-dir/files。存儲(chǔ)包 zip 存檔的目錄。
  • cache-repo-dir: 默認(rèn)為 $cache-dir/repo。存儲(chǔ) composer 類型的 VCS(svn、github、bitbucket) repos 目錄。
  • cache-vcs-dir: 默認(rèn)為 $cache-dir/vcs。此目錄用于存儲(chǔ) VCS 克隆的 git/hg 類型的元數(shù)據(jù),并加快安裝速度。
  • cache-files-ttl: 默認(rèn)為 15552000(6個(gè)月)。默認(rèn)情況下 Composer 緩存的所有數(shù)據(jù)都將在閑置6個(gè)月后被刪除,這個(gè)選項(xiàng)允許你來(lái)調(diào)整這個(gè)時(shí)間,你可以將其設(shè)置為0以禁用緩存。
  • cache-files-maxsize: 默認(rèn)為 300MiB。Composer 緩存的最大容量,超出后將優(yōu)先清除舊的緩存數(shù)據(jù),直到緩存量低于這個(gè)數(shù)值。
  • prepend-autoloader: 默認(rèn)為 true。如果設(shè)置為 false,composer autoloader 將不會(huì)附加到現(xiàn)有的自動(dòng)加載機(jī)制中。這有時(shí)候用來(lái)解決與其它自動(dòng)加載機(jī)制產(chǎn)生的沖突。
  • autoloader-suffix: 默認(rèn)為 null。Composer autoloader 的后綴,當(dāng)設(shè)置為空時(shí)將會(huì)產(chǎn)生一個(gè)隨機(jī)的字符串。
  • optimize-autoloader Defaults to false. Always optimize when dumping the autoloader.
  • github-domains: 默認(rèn)為 ["github.com"]。一個(gè) github mode 下的域名列表。這是用于GitHub的企業(yè)設(shè)置。
  • notify-on-install: 默認(rèn)為 true。Composer 允許資源倉(cāng)庫(kù)定義一個(gè)用于通知的 URL,以便有人從其上安裝資源包時(shí)能夠得到一個(gè)反饋通知。此選項(xiàng)允許你禁用該行為。
  • discard-changes: 默認(rèn)為 false,它的值可以是 truefalsestash。這個(gè)選項(xiàng)允許你設(shè)置在非交互模式下,當(dāng)處理失敗的更新時(shí)采用的處理方式。true 表示永遠(yuǎn)放棄更改。"stash" 表示繼續(xù)嘗試。Use this for CI servers or deploy scripts if you tend to have modified vendors.

實(shí)例:

{
    "config": {
        "bin-dir": "bin"
    }
}

scripts (root-only)

Composer 允許你在安裝過(guò)程中的各個(gè)階段掛接腳本。

更多細(xì)節(jié)和案例請(qǐng)查看 腳本。

extra

任意的,供 scripts 使用的額外數(shù)據(jù)。.

這可以是幾乎任何東西。若要從腳本事件訪問(wèn)處理程序,你可以這樣做:

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

可選。

bin

該屬性用于標(biāo)注一組應(yīng)被視為二進(jìn)制腳本的文件,他們會(huì)被軟鏈接到(config 對(duì)象中的)bin-dir 屬性所標(biāo)注的目錄,以供其他依賴包調(diào)用。

詳細(xì)請(qǐng)查看 Vendor Binaries。

可選。

archive

這些選項(xiàng)在創(chuàng)建包存檔時(shí)使用。

支持以下選項(xiàng):

  • exclude: 允許設(shè)置一個(gè)需要被排除的路徑的列表。使用與 .gitignore 文件相同的語(yǔ)法。一個(gè)前導(dǎo)的(!)將會(huì)使其變成白名單而無(wú)視之前相同目錄的排除設(shè)定。前導(dǎo)斜杠只會(huì)在項(xiàng)目的相對(duì)路徑的開(kāi)頭匹配。星號(hào)為通配符。

實(shí)例:

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

在這個(gè)例子中我們 include /dir/foo/bar/file、/foo/bar/baz、/file.php/foo/my.test 但排除了 /foo/bar/any、/foo/baz、/my.test。

可選。