composer.json 架構#

本章將說明 composer.json 中所有可用的欄位。

JSON 架構#

我們有可記錄格式的文件中 JSON 架構，並可將其用於驗證您的 composer.json。事實上，它是 validate 指令所使用。您可以在這裡找到它：https://composer.dev.org.tw/schema.json

根套件#

根套件是專案根目錄中 composer.json 所定義的套件。它主要的 composer.json 會定義專案需求。

只有在根套件內容中時，某些欄位才會套用。config 欄位就是一個例子。只有根套件才能定義設定。套件的設定會被忽略。這會使得 config 欄位成為 僅限根目錄。

注意：套件可以是根套件，或不是，這取決於內容。例如，如果您的專案有依賴 monolog 函式庫，您的專案就是根套件。但是，如果您從 GitHub clone monolog เพื่อ修正其中的錯誤，那 monolog 就是根套件。

屬性#

名稱#

套件名稱。它包括廠商名稱和專案名稱，並以/分隔。範例

  • monolog/monolog
  • igorw/event-source

名稱必須是小寫，且包含以-、.或_分隔的字詞。完整名稱應符合^[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-dev
  • 1.0.0-alpha3
  • 1.0.0-beta2
  • 1.0.0-RC5
  • v2.0.4-p1

如果套件存放庫可以從某處推論版本，例如 VCS 存放庫中的 VCS 標籤名稱，則 optional。在這種情況下，也建議省略它。

注意：Packagist 使用 VCS 存放庫，因此上述陳述對於 Packagist 來說也是非常正確的。自己指定版本很可能會在某個時間點由於人為錯誤而導致問題。

類型#

套件類型。它預設為library。

套件類型用於自訂安裝邏輯。如果你有需要一些特殊邏輯的套件，你可以定義一個自訂類型。這可能是一個symfony-bundle、wordpress-plugin或typo3-cms-extension。這些類型將全部專屬於某些專案，而且它們需要提供能夠安裝該類型的套件的安裝程式。

在盒子上，Composer 支援四種類型

  • library：這是預設值。它會將檔案複製到vendor。
  • project：這表示專案而不是函式庫。例如，像Symfony 標準版這樣的應用殼層、像Silverstripe 安裝程式這樣的 CMS 或以套件形式散布的完整功能應用程式。例如，IDE 可以使用它來提供在建立新的工作空間時要初始化的專案清單。
  • metapackage：一個空的套件，包含 requirement，並會觸發它們的安裝，但不會包含任何檔案，也不會寫入任何東西到檔案系統。因此，它不需要 dist 或 source 鍵就能安裝。
  • composer-plugin: 類型 composer-plugin 的套件可以為具有自定類型的其他套件提供安裝程式。請閱讀更多相關說明專門文章。
  • php-ext 和 php-ext-zend: 這些名稱保留給以 C 編寫的 PHP 延伸套件。請勿將這些類型用於以 PHP 編寫的套件。

只有在安裝過程中需要自定邏輯時才使用自定類型。建議省略此欄位，並將其預設值設為 library。

keywords#

套件相關的一系列關鍵字。這些關鍵字可用於搜尋和篩選。

範例

  • 記錄
  • 事件
  • 資料庫
  • redis
  • 範本

註解: 有些特殊關鍵字會在沒有 --dev 選項的情況下觸發 composer require，並提示使用者是否要將這些套件加入 require-dev 而不是 require。關鍵字包括：dev、testing、static analysis。

註解: 字串中允許使用的字元範圍限制在 Unicode 字母或數字、空白 " "、句點 .、底線 _ 和連字號 -。（正規表示法：'{^[\p{N}\p{L} ._-]+$}u'）執行 composer validate 時，使用其他字元會發出警告，並導致套件在 Packagist.org 上的更新作業失敗。

選用。

homepage#

專案網站網址。

選用。

readme#

readme 文件的相對路徑。預設值為 README.md。

這主要適用於不在 GitHub 上的套件，因為對於 GitHub 套件，Packagist.org 將使用 readme API 取得 GitHub 偵測到的 readme。

選用。

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

也可以使用「或」符號分隔並加上括號；

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

同樣地，當需要套用多個授權（「連接授權」）時，應使用「與」符號分隔並加上括號。

authors#

套件的作者。這是一個物件陣列。

每個 author 物件都可以具有下列特性

  • name: 作者的名字。通常是他們的真實姓名。
  • email: 作者的電子郵件地址。
  • homepage: 指向作者網站的 URL。
  • role: 作者在專案中扮演的角色（例如開發者或翻譯者）

範例

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

選擇性的，但強烈建議使用。

support#

各種取得專案支援的資訊。

支援資訊包含下列項目

  • email: 支援電子郵件地址。
  • issues: 指向問題追蹤器的 URL。
  • forum: 指向論壇的 URL。
  • wiki: 指向 Wiki 的 URL。
  • irc: 支援 IRC 頻道，格式為 irc://server/channel。
  • source: 瀏覽或下載原始碼的 URL。
  • docs: 指向文件檔案的 URL。
  • rss: 指向 RSS 摘要的 URL。
  • chat: 指向聊天頻道的 URL。
  • security: 指向漏洞揭露政策 (VDP) 的 URL。

範例

{
    "support": {
        "email": "support@example.org",
        "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 此外還支援「穩定性標記」（僅限根目錄）。其格式為「約束條款@穩定性標記」。這些標記讓您可以在 最小穩定性 設定範圍外，進一步限制或擴充封裝穩定性。您可以將這些標記套用到約束條款，或套用至空白的約束條款，例如讓您允許依賴項的不穩定封裝。

範例

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

如果您的某個依賴項有依賴關係建立在不穩定封裝上，您需要同時明確需要它，並加上其足夠的穩定性標記。

範例

假設 doctrine/doctrine-fixtures-bundle 需要 "doctrine/data-fixtures": "dev-master"，在 root 的 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 的 metadata 仍會在雜湊之前您指定的 branch 名稱中讀取。因此您只能將它用作開發期間的暫時解決方案，以修復暫時問題，直到您可以切換到標籤化版本。Composer 團隊不主動支援此功能，且不會接受與其相關的錯誤報告。

也可以內嵌別名封裝約束，使其符合原本不符的約束。如需詳細資訊，請參閱別名文章。

require 和 require-dev 也支援特定 PHP 版本和 PHP 延伸模組的參考，以便專案能順利執行。

範例

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

注意：列出專案所需的 PHP 延伸模組非常重要。並非所有的 PHP 安裝都相同：有些可能遺漏您可能會視為標準的延伸模組 (例如，預設不會於 Fedora/CentOS 最小安裝系統安裝的 ext-mysqli)。如果未列出所需的 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 元件，它們也能作為獨立的套件使用。如果您需要主套件，它將會自動滿足任何一個獨立元件的需求，因為它取代了它們。

在使用替換來達到上述子套件目的時，建議您謹慎為之。您應該僅使用 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 這樣的類時，一個命名空間字首 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"]
    }
}

Правила автоматичного завантаження files включаються щоразу, коли vendor/autoload.php включено відразу після реєстрації автозавантажувача. Порядок включення залежить від залежностей пакету, тож якщо пакет A залежить від B, спочатку будуть включені файли в пакеті B, щоб гарантувати, що пакет B повністю ініціалізований і готовий до використання, коли будуть включені файли з пакета A.

Якщо у двох пакетів однакова кількість залежностей або взагалі немає залежностей, порядок буде за абеткою.

Файли з кореневого пакета завжди завантажуються останніми, і ви не можете використовувати автоматичне завантаження files самостійно для перевизначення функцій зі своїх залежностей. Якщо ви хочете досягти цього, ми рекомендуємо включити власні функції до включення vendor/autoload.php Composer.

Виключити файли з map класів#

Якщо ви хочете виключити деякі файли або папки з map класів, ви можете використовувати властивість exclude-from-classmap. Це може бути корисним, наприклад, для виключення тестових класів у вашому робочому середовищі, оскільки вони будуть пропущені з map класів навіть під час створення оптимізованого автозавантажувача.

Генератор map класів ігноруватиме всі файли в шляхах, налаштованих тут. Шляхи є абсолютними від кореневого каталогу пакета (тобто місця розташування 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，而採用 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 設定項的套件都會在解析專案依賴關係時被忽略。（請注意，您也可以在「需要」區塊中指定的版本限制的穩定性標記中，針對每個套件個別指定穩定性需求（請參閱套件連結，以深入瞭解）。

可用的選項（依據穩定性排序）為 dev、alpha、beta、RC 和 stable。

prefer-stable (僅限根目錄)#

啟用這項設定時，當尋找相容的穩定套件時，Composer 將會優先選擇更穩定的套件。如果您需要開發版本，或套件只有 alpha 版本可供選擇，這些套件仍會被選取（最低穩定性許可的條件下）。

使用 "prefer-stable": true 進行啟用。

repositories (僅限根目錄)#

要使用的自訂套件存放庫。

預設情況下，Composer 只會使用 packagist 存放庫。透過指定存放庫，您可以從其它地方取得套件。

存放庫不會遞迴解析。您只能將它們新增到主要的 composer.json。將會忽略依賴項的 composer.json 中的存放庫宣告。

支援下列存放庫類型

  • composer: Composer 存放庫是一個透過網路（HTTP、FTP、SSH）提供的 packages.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://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"
        }
    }
}

config (僅根目錄)#

一組組態選項。僅用於專案。關於每個選項的說明，請參閱 組態。

scripts (僅根目錄)#

Composer 允許您透過使用腳本來連接安裝流程的各個部分。

有關活動詳情和範例，請參閱 腳本。

extra#

script 可使用的任意額外資料。

它幾乎可以是任何東西。若要從腳本事件處理常式存取它，您可以執行

$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#

表示此套件是否已被棄用。

它可以是布林值，或指向建議備案的套件名稱/網址。

範例

使用 "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）的父分支，您可以設定要當作開發版本處理的分支名稱模式。

當您具有使用「self.version」的依賴項時，這很有用，因此不會安裝 dev-master，而是安裝相同的分支（在此範例中：latest-testing）。

範例

如果您有一個在測試階段重度維護並部署到您的暫存環境的測試分支，通常 composer show -s 會給您 versions : * dev-master。

如果您將 latest-.* 設定為以下類似模式的非功能分支

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

那麼 composer show -s 將會給您 versions : * dev-latest-testing。

選用。

← 指令列介面 | 儲存庫 →

發現錯字？這份文件中有錯誤？分叉並編輯！