Laravel 11.x 貢献ガイド

バグレポートBug Reports

より積極的に援助して頂きたいため、Laravelではただのバグレポートでなく、プルリクエストしてくれることを強く推奨しています。プルリクエストは、”ready for review"（"draft"状態ではない）とマークされている場合にのみレビューされ、新しい機能のすべてのテストを通します。"draft"状態で残された残りの非アクティブプルリクエストは、数日後に閉じられます。To encourage active collaboration, Laravel strongly encourages pull requests, not just bug reports. Pull requests will only be reviewed when marked as "ready for review" (not in the "draft" state) and all tests for new features are passing. Lingering, non-active pull requests left in the "draft" state will be closed after a few days.

バグレポートを提出する場合にはその問題をタイトルに含め、明確に内容を記述してください。できる限り関連する情報や、その問題をデモするコードも含めてください。バグレポートの目的はあなた自身、そして他の人でも、簡単にバグが再現でき修正されるようにすることです。However, if you file a bug report, your issue should contain a title and a clear description of the issue. You should also include as much relevant information as possible and a code sample that demonstrates the issue. The goal of a bug report is to make it easy for yourself - and others - to replicate the bug and develop a fix.

バグレポートは、同じ問題を持つ他の人があなたと協力して解決してくれることを期待して作成することを忘れないでください。バグレポートに自動で何らかの活動が表示されたり、他の人がその問題の解決に飛びついたりすることを期待しないでください。バグレポートを作成することは、あなた自身や他の人が問題を解決する道を歩み始める手助けになります。もしあなたが協力したければ、issueトラッカーに記載しているバグを修正することで協力できます。LaravelのすべてのIssueを表示するには、GitHubで認証する必要があります。Remember, bug reports are created in the hope that others with the same problem will be able to collaborate with you on solving it. Do not expect that the bug report will automatically see any activity or that others will jump to fix it. Creating a bug report serves to help yourself and others start on the path of fixing the problem. If you want to chip in, you can help out by fixing any bugs listed in our issue trackers[https://github.com/issues?q=is%3Aopen+is%3Aissue+label%3Abug+user%3Alaravel]. You must be authenticated with GitHub to view all of Laravel's issues.

Laravelを使っているときに、DocBlock、PHPStan、IDEの警告に気づいた場合は、GitHub issueを作成しないでください。代わりに、問題を解決するための、プルリクエストを提出してください。If you notice improper DocBlock, PHPStan, or IDE warnings while using Laravel, do not create a GitHub issue. Instead, please submit a pull request to fix the problem.

LaravelのソースコードはGitHubで管理され、各Laravelプロジェクトのリポジトリが存在しています。The Laravel source code is managed on GitHub, and there are repositories for each of the Laravel projects:

質問のサポートSupport Questions

LaravelのGitHubイシュートラッカーは、Laravelのヘルプやサポートの提供を目的としていません。代わりに以下のチャンネルを利用してください。Laravel's GitHub issue trackers are not intended to provide Laravel help or support. Instead, use one of the following channels:

コア開発の議論Core Development Discussion

新機能や、現存のLaravelの振る舞いについて改善を提言したい場合は、LaravelフレームワークリポジトリのGitHub discussion boardへお願いします。新機能を提言する場合は自発的に、それを完動させるのに必要な、コードを最低限でも実装してください。You may propose new features or improvements of existing Laravel behavior in the Laravel framework repository's GitHub discussion board[https://github.com/laravel/framework/discussions]. If you propose a new feature, please be willing to implement at least some of the code that would be needed to complete the feature.

バグ、新機能、既存機能の実装についてのざっくばらんな議論は、Laravel Discord serverの#internalsチャンネルで行っています。LaravelのメンテナーであるTaylor Otwellは、通常ウイークエンドの午前８時から５時まで（America/Chicago標準時、UTC-6:00）接続しています。他の時間帯では、ときどき接続しています。Informal discussion regarding bugs, new features, and implementation of existing features takes place in the #internals channel of the Laravel Discord server[https://discord.gg/laravel]. Taylor Otwell, the maintainer of Laravel, is typically present in the channel on weekdays from 8am-5pm (UTC-06:00 or America/Chicago), and sporadically present in the channel at other times.

どのブランチ？Which Branch?

すべてのバグフィックスは、バグフィックスをサポートする最新バージョン (現在は 11.x) へ送るべきです。次期リリースにのみ存在する機能を修正する場合を除き、バグ修正を決して、masterブランチに送ってはいけません。All bug fixes should be sent to the latest version that supports bug fixes (currently 11.x). Bug fixes should never be sent to the master branch unless they fix features that exist only in the upcoming release.

現在のリリースと完全な下位互換性があるマイナーな機能は、最新の安定版ブランチ（現在は11.x）へ送ってください。Minor features that are fully backward compatible with the current release may be sent to the latest stable branch (currently 11.x).

メジャーな新機能や互換性のない変更を含む機能は、常に次のリリースに含まれるmasterブランチへ送ってください。Major new features or features with breaking changes should always be sent to the master branch, which contains the upcoming release.

アセットのコンパイルCompiled Assets

laravel/laravelリポジトリのresources/cssやresources/js下のほとんどのファイルのように、コンパイル済みファイルに影響を及ぼすファイルへ変更を行う場合、コンパイル済みファイルをコミットしないでください。大きなファイルサイズであるため、メンテナは実際レビューできません。悪意のあるコードをLaravelへ紛れ込ませる方法を提供してしまいます。これを防御的に防ぐため、すべてのコンパイル済みファイルはLaravelメンテナが生成しコミットします。If you are submitting a change that will affect a compiled file, such as most of the files in resources/css or resources/js of the laravel/laravel repository, do not commit the compiled files. Due to their large size, they cannot realistically be reviewed by a maintainer. This could be exploited as a way to inject malicious code into Laravel. In order to defensively prevent this, all compiled files will be generated and committed by Laravel maintainers.

セキュリティ脆弱性Security Vulnerabilities

Laravelにセキュリティー脆弱性を見つけたときは、メールでTaylor Otwell(taylorotwell@laravel.com)に連絡してください。全セキュリティー脆弱性は、速やかに対応されるでしょう。If you discover a security vulnerability within Laravel, please send an email to Taylor Otwell at taylor@laravel.com[mailto:taylor@laravel.com]. All security vulnerabilities will be promptly addressed.

コーディングスタイルCoding Style

LaravelはPSR-2コーディング規約とPSR-4オートローディング規約に準拠しています。Laravel follows the PSR-2[https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md] coding standard and the PSR-4[https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-4-autoloader.md] autoloading standard.

PHPDocPHPDoc

次に正しいLaravelのドキュメントブロックの例を示します。@param属性に続け２スペース、引数タイプ、２スペース、最後に変数名となっていることに注意してください。Below is an example of a valid Laravel documentation block. Note that the @param attribute is followed by two spaces, the argument type, two more spaces, and finally the variable name:

/**
 * Register a binding with the container.
 *
 * @param  string|array  $abstract
 * @param  \Closure|string|null  $concrete
 * @param  bool  $shared
 * @return void
 *
 * @throws \Exception
 */
public function bind($abstract, $concrete = null, $shared = false)
{
    // ...
}

ネイティブ型の使用により、@param属性や@return属性が冗長になる場合は、それらを削除することができます。When the @param or @return attributes are redundant due to the use of native types, they can be removed:

/**
 * Execute the job.
 */
public function handle(AudioProcessor $processor): void
{
    //
}

ただし、ネイティブ型が汎用型の場合は、@param属性または@return属性を用いて汎用型を指定してください。However, when the native type is generic, please specify the generic type through the use of the @param or @return attributes:

/**
 * Get the attachments for the message.
 *
 * @return array<int, \Illuminate\Mail\Mailables\Attachment>
 */
public function attachments(): array
{
    return [
        Attachment::fromStorage('/path/to/file'),
    ];
}

StyleCIStyleCI

コードのスタイルが完璧でなくても心配ありません。プルリクエストがマージされた後で、StyleCIが自動的にスタイルを修正し、Laravelリポジトリへマージします。これによりコードスタイルではなく、貢献の内容へ集中できます。Don't worry if your code styling isn't perfect! StyleCI[https://styleci.io/] will automatically merge any style fixes into the Laravel repository after pull requests are merged. This allows us to focus on the content of the contribution and not the code style.

行動規範Code of Conduct

Laravelの行動規範はRubyの行動規範を基にしています。行動規範の違反はTaylor Otwell(taylor@laravel.com)へ報告してください。The Laravel code of conduct is derived from the Ruby code of conduct. Any violations of the code of conduct may be reported to Taylor Otwell (taylor@laravel.com[mailto:taylor@laravel.com]):