web-dev-qa-db-ja.com

Composer-ローカルリポジトリを使用

私はComposer初心者であり、1つのプロジェクトを別のプロジェクトに依存させようとしていますが、両方のプロジェクトはローカルマシンにのみ存在しています。

ライブラリプロジェクト(ProjectA)のcomposer.jsonは次のとおりです。

{
    "name" : "project/util",
    "type" : "library"
}

このプロジェクトのベースフォルダーでgitを初期化しました。

最初のプロジェクト(ProjectB)に依存するプロジェクトのcomposer.json:

{
    "repositories": [
        {
            "name" : "util", 
            "type" : "git",
            "url" : "/d/workspaces/util"
        }   
    ],

    "require": {
        "project/util" : "*"
    },
}

ProjectBからcomposer installを実行すると、次のエラーが表示されます。

[RuntimeException]
Failed to clone , could not read packages from it
fatal: repository '' does not exist

リポジトリのURLに何か問題があると思いますが、他に何を書き込むべきかはわかりません。

46
Banana

composerを使用してローカルパッケージを自動ロードします(変更するたびにpackagistにアクセスすることはありません)。

そのための方法はたくさんありますが、そのうちの2つを取り上げます。

すべての場合に2つの主要なパーティがあります:
-ローカルパッケージ(プロジェクトコンポーザーで自動読み込みできるように、packagistで公開したくないコード)。
-メインプロジェクト(ローカルパッケージコードを使用する必要のあるコードベース。別のパッケージまたはプロジェクトにすることができます)。


方法1:(直接名前空間)

メインプロジェクトを開きますcomposer.jsonファイルを作成し、任意の方法(PSR-4、PSR-0、...)を使用してローカルパッケージの名前空間を自動ロードします。

例:

ローカルパッケージのcomposer.jsonにある場合:

  "autoload": {
    "psr-4": {
      “Local\\Pack\\": "library"
    }
  },
  "autoload-dev": {
    "psr-4": {
      "Local\\Pack\\Tests\\": "tests"
    }
  },

次に、メインプロジェクトのcomposer.jsonに次のようにします。

  "autoload": {
    "psr-4": {
      "Mahmoudz\\Project\\": "src",
      "Local\\Pack\\": "../path/to/local/pack/library”                   << referencing the other local package
    }
  },
  "autoload-dev": {
    "psr-4": {
      "Mahmoudz\\Project\\Tests\\": "tests"
    }
  },

利点:
-ベンダーディレクトリに触れない(composer誤って更新してもローカルの変更は上書きされません)
-パッケージを使用するためにパッケージをパガジストにする必要はありません
-1つの場所(ローカルパッケージ)で作業すると、変更がメインプロジェクトに自動的にロードされます。
欠点:
-composer.jsonを実稼働で公開することはできません(公開前に実際のパッケージを要求するには編集が必要です)

方法2:(ローカルリポジトリ)

ローカルリポジトリからローカルパッケージをダウンロードします。

ローカルパッケージ:
1。パッケージ内のgitを初期化します(使用したくない場合でも、何もコミットする必要はありません)
2。 composer.jsonファイルを追加します。ファイルには、次のものがあることを確認してください。

"name": "vendor-name/package-name",  

"autoload": { …   // use whichever method you prefer, but make sure it’s being loaded correctly

"minimum-stability": "dev"  
  1. composer dump-autoload

メインプロジェクト:
1。 composer.jsonを編集して、以下を含めます。

  "repositories": [
    {
      "type": "vcs",
      "url": "/full/path/to/the/local/package/package-name"
    }
  ],
  "require": {
    "vendor-name/package-name": "dev-master"
  },
  1. コンポーザー更新ベンダー名/パッケージ名
  2. ベンダーディレクトリを確認して、vendor-name/package-nameを確認してください。

注:ローカルパッケージ(ベンダーではなく)を変更するたびにgit commitを行う必要があります。その後、composer=メインプロジェクトを更新すると、メインのリポジトリの最新コピーが取得されますプロジェクトベンダーディレクトリ。

利点:
-ベンダーディレクトリに触れない(composer誤って更新してもローカルの変更は無効になりません)-パッケージを使用するためにパッケージが必要ではありません)それ
欠点:
-(ローカルパッケージで)変更をコミットし続けてから、メインプロジェクトでcomposer updateを実行する必要があります。
-composer.jsonを実稼働で公開することはできません(公開前に実際のパッケージを要求するには編集が必要です)

42
Mahmoud Zalt

構文が間違っていると思います。タイプはVCSである必要があり、composer= VCSのタイプがわかります。

プロジェクトBでは、リポジトリのエントリは次のようになります。

"repositories": [
    {
        "type": "vcs",
        "url" : "/d/workspaces/util"
    }
],

/d/workspaces/utilで利用可能なライブラリに名前を付ける必要はありません。 Composerはそのディレクトリ内のcomposer.jsonファイルをスキャンし、そこで使用可能なプロジェクト名を認識し、packagistまたは他のリポジトリにリストされているバージョンよりもそのディレクトリのプロジェクトを優先して使用します。

23
Danack

Danackのソリューションに加えて、パスを/ d /からd:/に変更するとうまくいきました。

このような:

"repositories": [
    {
        "type": "vcs",
        "url" : "d:/workspaces/util"
    }
],
2
Max

私はこのチュートリアルが本当に便利だと感じました: https://johannespichler.com/developing-composer-packages-locally/ ローカルパッケージの生産で問題に直面したとき

ベンダーフォルダーをシンボリックリンクにできるsymlink条件に注意してください。これにより、composer update変更を確認するたびに

"options": {
        "symlink": true
      }
0
Friendly Code