私は_Composerプロキシサービス/リポジトリ_を構築中です。 ミニサービスのアイデアは、_WordPress_API応答からテーマまたはプラグインの言語/翻訳パッケージを動的に配信することです。 ルートは次のとおりです。
https://api.wordpress.org/translations/plugins/1.0/?slug={slug}&version={version}
_Nodejs_-service自体は、 type:project
composer.json
にtype:project
repository
として追加する必要があるプロキシにすぎません。 サービス自体は、(動的に生成された) packages.json
ファイルの一部としてproviders-url
キーを返します。
"providers-url" : "/" + request.params.scope + "/providers/%package%$%hash%.json"
例については、次のcomposer.json
を参照してください。
{
"name" : "vendor/testproject",
"type" : "wordpress-project",
"minimum-stability" : "dev",
"repositories" : [
{
"type" : "composer",
"url" : "https://{unique-ID}.ngrok.io/test"
}
]
}
これまでのところ、 /endpoint/packages.json
へのリクエストのみを表示できますが、パラメーターは表示されません。 理想的な世界では、Composerはrequired
パッケージをヘッダーまたはクエリパラメーターとして送信します。
私はすでに、利用可能なすべてのオプションを調べて(そしてテストして)、システムを_偽造_して、要求されたパッケージtype:{composer|vcs|…}
取得しようとしました。 これを実現する方法はありますか? または、少なくとも、これを実装するためのPRを受け入れる_will_がありますか?その動作を有効にするための追加のフラグと一緒に?
ホスティングサービスに関する_Aノート:の組み合わせがあるかもしれませんnotify-batch
とrequest/require
を検索し、実際にフェッチされたリポジトリに関するいくつかの統計情報を収集するためのオプション。 このアプローチにより、「キャッシュする」パッケージをより適切にターゲットにできる可能性があります。_
現時点ではこれは不可能であり、しばらくはそうなるとは思えません。おそらくv2.0では、プールの要素をリファクタリングすると、これを実現できます。 とりあえず開いたままにしておきますが、息を止めないでください:)
@alcoholラベルを今すぐ調整できると思います:)
ここでmetadata-url: "/p2/%package%.json"
を実行でき、必要なすべてのパッケージが1つと呼ばれるため、v2メタデータ(詳細に興味がある場合はトラック#8248)で実行できる可能性があります。ただし、他のパッケージではなく、そのパッケージの名前のデータのみを返すことができるため、実際に役立つかどうかはわかりません。
ある程度その場でパッケージを生成できるので、プラグインにfoo/plugin-translations-en
を要求させてから、常にパッケージを返して、インストール可能であることを確認することができます。翻訳が利用できない場合、何もインストールしない空のメタパッケージ?
最も参考になるコメント
現時点ではこれは不可能であり、しばらくはそうなるとは思えません。おそらくv2.0では、プールの要素をリファクタリングすると、これを実現できます。 とりあえず開いたままにしておきますが、息を止めないでください:)