web-dev-qa-db-ja.com

Composerパッケージを開発して含める方法は？

PHPでパッケージを開発したいと考えていますが、GitHubまたはどこかですぐに利用できるようにしたくありません。 Packagistファイルをcomposer.jsonに含めるのは簡単ですが、ローカルパッケージをcomposer.jsonに追加するにはどうすればよいですか？また、パッケージを/vendor/foo/bar（ルートcomposer.jsonに対して）に構築する必要がありますか、それとも別の場所に配置する必要がありますか？

編集：私の質問は、他の全員がどのようにパッケージを書くかについてです。すべての新しいパッケージがPackagistに追加され、変更をテストするときにGitHub（またはどこでも）にコミットし、Composerを介してそれをプルダウンしますか？それは本当に非効率的です。

phpcomposer-php
53
greggilbert

この質問には多くの異なるコンポーネント/標準が説明されているため、ここで可能な限り説明するようにします。具体的な質問については、PMまたはGoogleだけで説明します。

最初の質問に答えるには、「ローカルパッケージをcomposer.jsonに追加するにはどうすればよいですか？」：

「ローカルパッケージの追加」とは、クラス/パッケージの自動ロードを意味する場合、PSR-4またはPSR-0またはcomposerのClassmapオプションを使用してそれを行うことができます。

続きを読む

PSR-0、PSR-4、およびClassmapの詳細情報が必要な場合は、Googleで検索できます。

例

"autoload": {
   "psr-4": { "Core\\": "src/Core" }  ## "standard": { "namespace" : "path/to/dir"}
}

または（編集）

ローカルパッケージを実際に追加する場合：

  1. 次のように、ローカルパッケージのcomposer.jsonを作成します。

    {
   "name": "localPackage/core",
   "version": "dev-master"
}

    必要に応じて、他のプロパティや依存関係を指定することもできます。

  2. composer.jsonのルートファイルとしてarchive.Zipファイルを使用してパッケージを圧縮し、必要な場所に配置します。

  3. ローカルパッケージを含める他のプロジェクト/パッケージで、次のようにローカルパッケージ名を必須パラメーターに追加します。

    "localPackage/core": "dev-master"

    repositoriesパラメーターの下に以下を追加します。

    "repositories" : [
    {
        "type": "artifact",
        "url": "path/to/localPackage.Zip"
    }
]

Gitにローカルパッケージがある場合、パッケージをアーカイブする必要はなく（基本的に手順2は省略）、上記の例のURLをpath/to/localPackage/.gitに置き換えるだけです。

（編集の終了）

ここで、「Composerパッケージを開発して組み込むにはどうすればよいですか？」という大きな質問に答えます。

  1. ディレクトリ構造を決定します。一般的には次のとおりです。

    /PackageRoot
    /src/PackageCore
    composer.json   ## this is your library’s composer.json
    LICENSE

    composer.jsonを設定します。

    私のcomposer.jsonファイルの例は http://Pastebin.com/tyHT01Xg にあります。

  2. Github および バージョンにタグ付け にアップロードします。 セマンティックバージョニング を使用します（Githubへのアップロード時にvendorディレクトリを除外/無視することを確認してください）。

  3. パッケージを Packagist で登録します（ログイン後）。

    コミットにv1.0.0（または同様の）のタグを付けた場合、そのパッケージのPackagistダッシュボードに表示されます。

これで、すべてが正しく行われた場合、ライブラリをそのプロジェクトのcomposer.jsonに追加することにより、ライブラリを他のプロジェクトの依存関係として使用できるようになります。

25
ShalomSam

新しいリポジトリを作成する代わりに、composerにローカルパスを使用するように指示できます。

https://getcomposer.org/doc/05-repositories.md#path

たとえば、PHPプロジェクトが~/devel/projectsの下にあるとしましょう。

~/devel/projects/main_projectにメインプロジェクトがあり、~/devel/projects/local_packageに「ローカルパッケージ」がある場合があります

ローカルパッケージのcomposer構成を定義します。 ~/devel/projects/local_package/composer.jsonで。

{
    "name": "your_vendor_id/your_local_package",
    ...
}

次に、~/devel/projects/main_project/composer.jsonを編集し、パスリポジトリ経由でローカルパッケージにリンクします。

"repositories": [
    {
        "type": "path",
        "url": "../local_package",
        "options": {
            "symlink": true
        }
    }
],
"require": {
    "your_vendor_id/your_local_package": "dev-master",
    ...
}

このリンクに関する詳細情報（私が書いたのではありませんが、このテーマについては十分な説明があります）：

https://carlosbuenosvinos.com/working-at-the-same-time-in-a-project-and-its-dependencies-composer-and-path-type-repository/

20
Federico J. Álvarez Valero

このスレッドに関するほとんどの答えは「知っている」ものではないようです。私はComposer自分ですが、これらの答えは誤解を招くものです。質問は、「composerパッケージを開発するにはどうすればよいですか？」.

はい。カスタムリポジトリを使用するか、未完成のパッケージをアップロードして、変更のたびに更新できます。それは正しい解決策でも、質問に対する答えでもありません。

Composerの公式ドキュメント がこれを前もって述べていないのは助けにはなりませんが、 ライブラリドキュメントページ で見出しを見ることができます：

すべてのプロジェクトはパッケージです

これは理解することが非常に重要です

composer.json：

前述のページは次の状態に進みます。

そのパッケージをインストール可能にするには、名前を付ける必要があります。これを行うには、composer.jsonにnameプロパティを追加します

{
    "name": "acme/hello-world",
    "require": {
        "monolog/monolog": "1.0.*"
    }
}

これまでの例では、必要なパッケージがあり、名前が付けられました。 vendor/name形式に注意してください。

基本的な使用法 ページに記載されている独自のファイルを自動ロードします。

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

これにより、src/Acmeディレクトリの下の名前空間付きクラスファイルが自動ロードされます。

楽しみに。

更新プログラムをインストールします

次のコマンドでパッケージをインストールまたは更新します。

composer update

または

php composer.phar update

これにより、必要なパッケージがダウンロードされ、autoload.phpファイルが作成されます

プロジェクト構造は次のようになります。

src
    Acme
        Foo.php
vendor
    monolog
        ...
composer.json

含む

次にテストします。

Autoload.phpを含める

require_once 'path/to/project/vendor/autoload.php';

Foo.phpが次のようになっていると仮定します。

<?php

namespace Acme;

class Foo {
    public static function bar(){
        return 'baz';
    }
}

?>

次に、スクリプトからこれを呼び出すことができます。

echo Acme\Foo::bar(); // baz

私が述べたかもしれない誤解を招く情報を修正してください。これは、一般的な質問の解決策と思われるものです。

9
iautomation

ここにソリューションの要約と自分のソリューションがあります

  1. packagistで公開する

あなたはまだ公開したくないので、あなたは開発中です、これは貧弱なオプションです。

  1. githubをアップロード

ライブラリソースをgithubに公開したり、プライベートリポジトリの支払いをしたり、クラウドの外部サービスを使用したりすることはできません（政治的またはネットワークポリシーにより）。

  1. ライブラリを圧縮する

サンプル実装でcomposerリポジトリパスを使用して、リリースとしてローカルZipファイルを指すことができます。libに変更を加えるたびに、Zipを再圧縮する必要があります。それを行うためのバッチファイルでは、これは厄介です。

  1. マシンのローカルgit/svnリポジトリにアップロードします

これは近づいていますが、ライブラリを変更して実装例をテストするたびにcomposer更新を行う必要があります。これは実稼働環境を模倣しますが、面倒です。 、それは無知ではありませんが。

  1. ライブラリを直接自動ロードします（sortofは必要なことを行います）

これはハックですが、追加するだけです：

{    
  "require": {
  },
  "autoload": {
    "psr-4": { 
      "yourlibnamespace": "D:\\Code\\yourlib\\src\\" 
    }
  }

}

Libからサンプル実装に「require」セクションをコピーして貼り付ける必要があることに注意してください。 「yourlibnamespace」をライブラリのネームスペースに変更し、「D：\ Code\yourlib\src \」をライブラリソースのローカルパスに変更します。

これにより、変更がすぐに反映されます。ただし、ライブラリのcomposer.jsonファイルを使用またはテストすることは一切ありません。ライブラリ.jsonの要件を変更すると、要件はまったく流れません。したがって、いくつかの大きな欠点がありますが、必要なコマンドを実行して、ライブラリの実装を最小限のコマンドですぐにテストします。

  1. ライブラリツリーにサンプル実装を直接追加します（推奨）

通常、src \とtests \だけがありますが、多くにはサンプルの実装が見つかるexamples \があります。アプリケーションを開発するときに、これらの実装例に貢献できます。これはローカルgit/svnリポジトリで行うことができ、libの「require」に加えてネームスペースを自動的に取得できるという利点があります。それはすべての世界の最高です。この方法をお勧めします。

7
Finlay Beaton

開発をより効率的にするために、開発リポジトリを既にインストールされているディレクトリにシンボリックリンクするだけです。

たとえば、/Code/project-1に/Code/package-1にあるパッケージが必要な場合、I：

  1. package-1をGitHubにコミットします（プライベートにすることもできます）。
  2. 次に、project-1にカスタムリポジトリを使用してインストールするように指示します（リポジトリ構成へのリンクについては他の回答を参照してください）。
  3. インストールしたら、/Code/project-1/vendor/developer/package-1を/Code/package-1にシンボリックリンクします。

そうすれば、/Code/package-1を変更すると、すぐに/Code/project-1に反映されます。

5
Adam Engebretson

カスタムリポジトリを追加すると役立つかもしれません。

https://github.com/composer/composer/blob/master/doc/05-repositories.md

ライブラリでローカルgitリポジトリを非常に簡単に設定できます。

もちろん、依存関係を管理するためにcomposerを使用する場合は、ライブラリを他の場所でビルドし、ベンダーにダウンロードする必要がありますcomposer coz 。

5
fsw

これが、新しいComposerパッケージをローカルで作成および開発する私のフローです。

  1. GitHubでパッケージの新しいリポジトリを作成する（ほんの一例）
  2. Composerのデータベース（packagist.org）に追加します
  3. composer require。を使用してメインプロジェクトに追加します。ここで、修正プログラムをすばやく適用する方法について考え始めます。
  4. それをどこかのローカルマシンにクローンします、これはあなたがそれを開発する場所です
  5. ローカルバージョンをテストするには、問題のクラスファイルをロードするphp require（）ステートメントを追加します。オートローダーは、composer経由でダウンロードされたものではなく、ローカルのものをロードします。
  6. ホットフィックスが完了したら、requireステートメントを削除/コメントアウトして、composerパッケージのバージョンを使用するように戻ります。
  7. すべての変更をコミットし、コミットにタグを付けてGitHubにプッシュします。 Composerを更新するためにフックが起動します。メインプロジェクトでcomposer updateを実行すると、パッケージがローカルバージョンに更新されます。

これはまだ理想的ではありませんが、小規模から中規模のパッケージで作業が完了します。

5
George Kagan

私のワークフローはOPの質問に完全に答えているわけではありませんが、他の人にとっては役立つかもしれません。

  1. 私は現実世界のプロジェクトで再利用可能なパッケージ/ libを開発したいのですが、git/composer local。
  2. また、本番とは異なる方法でパッケージをローカルにロードすることも好みません（たとえば、ローカルのrequireステートメントまたはlocal composer設定）を使用します）。

したがって、私がしていることは簡単です。ベンダーディレクトリの下に直接、またはシンボリックリンクを使用してパッケージを追加します。

欠点

  1. composer update/installを使用すると、パッケージが上書きされる可能性があります（したがって、この間に依存関係を1つずつ更新または追加する傾向があります）。
  2. 注意しないと、composer本番環境にインストールすると異なるバージョンがインストールされる可能性があります。パッケージとバージョンタグをプッシュし続けてください!!
  3. パッケージの依存関係を変更し、親プロジェクトにロードするcomposer= update、package's folder
0
roelleor