差分

このページの2つのバージョン間の差分を表示します。

--- packagist:knowledge [2020/07/17 11:10]
y2sunlight [composer.jsonの作成]
+++ packagist:knowledge [2020/07/17 16:14] (現在)
y2sunlight [更新スケジュール]
@@ 行 1: / 行 1: @@
-> 編集中
 ====== Packagist パッケージ登録の基礎知識 ======
  --- //[[http://www.y2sunlight.com|y2sunlight]] 2020-07-16//
@@ 行 22: / 行 20: @@
 ===== パッケージのネーミング =====
-First of all, you must pick a package name. This is a very important step since it can not change and it should be unique enough to avoid conflicts in the future.
-The package name consists of a vendor name and a project name joined by a /. The vendor name exists to prevent naming conflicts. For example, by including a vendor name both igorw and seldaek can have a library named json by naming their packages igorw/json and seldaek/json.
+( packagist でパッケージを提出するには ) まず第一に、パッケージ名を選択する必要があります。これは変更できないので非常に重要なステップであり、将来的に競合を回避するために十分に一意である必要があります。
-In some cases the vendor name and the package name may be identical. An example of this would be `monolog/monolog`. For projects with a unique name this is recommended. It also allows adding more related projects under the same vendor later on. If you are maintaining a library, this would make it really easy to split it up into smaller decoupled parts.
+パッケージ名は、スラッシュ( ''/'' ) で結合された ベンダー名 と プロジェクト名 で構成されます。ベンダー名は、名前の競合を防ぐために存在します。たとえば、ベンダー名を含めることにより、''igorw'' と ''seldaek'' の両方に、パッケージに ''igorw/json'' と ''seldaek/json'' という名前を付けて、''json'' という名前のライブラリーを作成できます。
-Here is a list of typical package names for reference:
+場合によっては、ベンダー名とパッケージ名が同じになることがあります。この例は、''monolog/monolog'' です。一意の名前を持つプロジェクトの場合、これが推奨されます。また、後で同じベンダーに関連プロジェクトを追加することもできます。ライブラリを保守している場合、これにより、ライブラリを小さく切り離したパーツに分割することが本当に簡単になります。
+参考の為に、典型的なパッケージ名のリストを次に示します：
 <code>
-// Monolog is a library, so the vendor name and package name are the same.
+// Monolog はライブラリで、ベンダー名とパッケージ名が同じです。
 monolog/monolog
-// That could be the name of a drupal module (maintained/provided by monolog,
+// これはdrupalモジュールの名前のようです（monolog によって保守/提供されてます。
-// if the drupal team did it, the vendor would be drupal).
+// drupalチームがそれを行っているとしたら、ベンダーはdrupalになります）。
 monolog/monolog-drupal-module
-// Acme is a company or person here, they can name their package with a common name (Email).
+// Acme は会社または人です。ここではパッケージに一般的な名前（Email）で名前を付けることができます。
-// As long as it's in their own vendor namespace it does not conflict with anyone else.
+// 独自のベンダー名前空間にある限り、他の誰とも競合しません。
 acme/email
 </code>
-Vendor names on packagist are protected once a package with that name has been published. That means you can not publish packages with a vendor name that already exists on packagist without permission. To be able to publish packages for an already existing vendor name you need to be maintainer of at least one package within that vendor.
+packagist のベンダー名は、ひとたび、その名前でパッケージが公開されると保護されます。つまり、packagist にすでに存在するベンダー名のパッケージを許可なしに公開することはできません。既存のベンダー名のパッケージを公開できるようにするには、そのベンダー内の少なくとも一つのパッケージの保守担当者である必要があります。
 \\
+===== パッケージのバージョン管理 =====
+パッケージの新しいバージョンは、バージョン管理システムのリポジトリに作成したタグから自動的にフェッチされます。
+バージョニングを管理する最も簡単な方法は、composer.json ファイルからバージョンフィールド( ''version'' )を省略することです。 その後は、バージョン番号はタグとブランチ名から解析されます。
+タグ/バージョン名は ''X.Y.Z'' または ''vX.Y.Z'' と一致する必要があり、RC, beta, alpha または patch バージョンのオプションのサフィックスが付いています。次に、有効なタグ名の例をいくつか示します:
+<code>
+.0.0
+v1.0.0
+.10.5-RC1
+v4.4.4beta2
+v2.0.0-alpha
+v2.0.4-p1
+</code>
+ブランチは自動的に "dev" バージョンとして表示され、ライブラリの最新かつ最高のものを試してみたい人なら誰でも簡単にインストールできますが、リリースにタグを付けてはいけないという意味ではありません。[[https://semver.org/lang/ja/|セマンティックバージョニング]]の使用を強くお勧めします。
+> 例えば、''dev-master'' は masterブランチの最新バージョンを表します。
+\\
 ===== composer.jsonの作成 =====
-The composer.json file should reside at the top of your package's git/svn/.. repository, and is the way you describe your package to both packagist and composer.
+composer.json ファイルは、パッケージの git/svn/などの リポジトリの先頭に配置する必要があり、packagist と composer の両方にパッケージについて説明する手段となります。
-A typical composer.json file looks like this:
+典型的な composer.json ファイルは次のようになります。
 <code json>
@@ 行 80: / 行 103: @@
 </code>
-Most of this information is obvious, keywords are tags, require are list of dependencies that your package has. This can of course be packages, not only a php version. You can use ext-foo to require php extensions (e.g. ext-curl). Note that most extensions don't expose version information, so unless you know for sure it does, it's safer to use "ext-curl": "*" to allow any version of it. Finally the type field is in this case indicating that this is a library. If you do plugins for frameworks etc, and if they integrate composer, they may have a custom package type for their plugins that you can use to install the package with their own installer. In the absence of custom type, you can omit it or use "library".
+この情報のほとんどは明白で、キーワード( ''keywords'' )はタグであり、パッケージが持つ依存関係のリスト( ''require'' )が必要です。もちろん、これはphpバージョンだけでなく、パッケージでもかまいません。''ext-foo'' を使用して、php拡張モジュールを要求できます（例：''ext-cur''l）。ほとんどの拡張モジュールはバージョン情報を公開しない点に注意して下さい。従って、確実に公開していない限り、''"ext-curl":"*"'' を使用して、どのバージョンでも許可する方が安全です。最後に、タイプフィールド( ''type'' )ですが、上記の場合は、これがライブラリであることを示しています。フレームワークなどに対するプラグインを作成し、それらが composer を統合している場合、独自のインストーラーを使用してパッケージをインストールするために使用できるプラグイン用のカスタムパッケージタイプがある場合があります。カスタムタイプがない場合は、それを省略するか、"ライブラリ" を使用できます。
+このファイルをリポジトリのルートでコミットしたら、パブリックリポジトリのURLを入力してパッケージを Packagist に[[https://packagist.org/packages/submit|送信]] できます。
+\\
+===== 更新スケジュール =====
+New packages will be crawled immediately after submission if you have JS enabled.
+JSを有効にしている場合、新しいパッケージは、送信後、即座にクロールされます。
+自動更新（GitHub / BitBucketフック）のない既存のパッケージは、更新のために週に1回クロールされます。フックを有効にすると、プッシュするたびに、パッケージがクロールされ、また、クロールが失敗した場合は少なくとも月に1回はクロールされます。保守担当者としてログインしている場合は、パッケージ画面で手動更新をトリガーすることもできます。
+すべてのパッケージに GitHubまたはBitBucketのサービスフックを設定することを強くお勧めします。これにより、負荷が軽減され、パッケージがほぼ瞬時に更新されます。以下のハウツーを確認してください。
+  * https://packagist.org/about　内の "How to update packages?" の項を参照して下さい。
+<div indent><div indent>
+GitHubの場合は、本編の「Packagist アカウントの作成」内の「[[packagist:register#githubパッケージの更新方法]]」に "How to update packages?" の翻訳が記載されています。
+</div></div>
-Once you have this file committed in your repository root, you can [[https://packagist.org/packages/submit|submit the package]] to Packagist by entering the public repository URL.
+検索インデックスは5分ごとに更新されます。検索インデクサーが最後に実行されてからクロールされたパッケージがインデックス（または再インデックス）されます。（※即ち、クロールされて（自動更新の場合はプッシュとほぼ同時刻）から最大で5分以内の再インデックスされるという事）
 \\

Ground Sunlight

ユーザ用ツール

サイト用ツール

差分

ページ用ツール