Подписывайтесь на наш Telegram канал и будьте в курсе всех событий.
Документация
●
Поддержите нас - каждый вклад важен!
Поддержите нас - каждый вклад важен!

Рекомендации по участию

Отчеты об ошибках

Чтобы стимулировать активное сотрудничество, Laravel настоятельно рекомендует запросы на слияние, а не только отчеты об ошибках. Запросы на слияние будут рассматриваться только в том случае, если они помечены как «готовые к рассмотрению» (не в состоянии «черновик») и все тесты для новых функций пройдены. Устаревшие неактивные запросы на слияние, оставшиеся в состоянии «черновик», будут закрыты через несколько дней.

Однако, если вы отправляете отчет об ошибке, ваш тикет о проблеме должен содержать заголовок и четкое описание проблемы. Вы также должны включить как можно больше релевантной информации и образец кода, демонстрирующий проблему. Цель отчета об ошибке – упростить для вас и окружающих воспроизведение ошибки и разработать исправления.

Помните, отчеты об ошибках создаются в надежде, что другие с той же проблемой смогут сотрудничать с вами при ее решении. Не ожидайте, что отчет об ошибке автоматически сподвигнет на какие-либо действия или что другие будут прыгать, чтобы исправить ее. Создание отчета об ошибке поможет вам и другим начать работу по устранению проблемы. Если хотите внести свой вклад, то вы можете помочь, исправив любые ошибки, перечисленные в нашем трекере тикетов ошибок. Вы должны пройти аутентификацию в GitHub, чтобы просмотреть все проблемы Laravel.

Если вы заметили неправильное использование DocBlock, предупреждения PHPStan или IDE при работе с Laravel, не создавайте issue на GitHub. Вместо этого, сделайте запрос на слияние для исправления проблемы.

В управлении исходным кодом Laravel используется GitHub, и для каждого проекта есть репозитории:

Вопросы поддержки

Трекеры с тикетами проблем Laravel на GitHub не предназначены для предоставления помощи или поддержки Laravel. Вместо этого используйте один из следующих каналов:

Обсуждение разработки ядра

Вы можете предлагать новый функционал или улучшения к уже существующему поведению в репозитории фреймворка Laravel на доске обсуждений GitHub. Если вы предлагаете новый функционал, то, пожалуйста, будьте готовы реализовать по крайней мере часть кода, который потребуется для его завершения.

Неформальное обсуждение ошибок, нового функционала и реализаций существующего происходит на канале #internals сервера Laravel Discord. Тейлор Отвелл, сопровождающий Laravel, обычно присутствует на канале в будние дни с 8:00 до 17:00 (UTC-06:00 или Америка / Чикаго) и от случая к случаю – в остальное время.

Какую ветку выбрать при запросах слияния?

Все исправления ошибок должны быть отправлены в последнюю версию, которая поддерживает исправления ошибок (на данный момент 11.x). Исправления ошибок никогда не должны отправляться в ветку master, если они не исправляют функции, которые существуют только в предстоящем выпуске.

Минорный функционал, полностью обратно совместимый с текущим релизом, может быть отправлен в последнюю стабильную ветку (в настоящее время 11.x)..

Мажорный новый функционал или функционал с изменениями, приводящими к нарушению обратной совместимости, должен всегда отправляться в ветку master, содержащую предстоящий релиз.

Скомпилированные ресурсы исходников

Если вы отправляете изменение, которое повлияет на скомпилированные файлы, например, касательно файлов в resources/css или resources/js репозитория laravel/laravel, то не включайте в коммит эти скомпилированные файлы. Из-за большого размера они не могут быть реально рассмотрены сопровождающим. Это может быть использовано как способ внедрения вредоносного кода в Laravel. Чтобы предотвратить это, все скомпилированные файлы будут сгенерированы и включены в коммит сопровождающими Laravel.

Уязвимости безопасности

Если вы обнаружите уязвимость в системе безопасности Laravel, отправьте электронное письмо Тейлору Отвеллу по адресу taylor@laravel.com. Все уязвимости безопасности будут незамедлительно устранены.

Стиль кодирования

Laravel следует стандарту кодирования PSR-2 и стандарту автозагрузки PSR- 4.

PHPDoc

Ниже приведен пример валидного блока документации Laravel. Обратите внимание, что за атрибутом @param идут два пробела, тип аргумента, еще два пробела и, наконец, имя переменной:

/**
 * 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 являются избыточными из-за использования нативных типов, их можно удалить:

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

Однако, когда нативный тип является обобщенным, укажите его через использование атрибутов @param или @return:

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

StyleCI

Не волнуйтесь, если стиль вашего кода не идеален! StyleCI автоматически объединит любые исправления стиля после слияния вашего запроса с репозиторием Laravel. Это позволяет нам сосредоточиться на содержании вашего вклада, а не на стиле кода.

Нормы поведения

Кодекс поведения Laravel основан на кодексе поведения Ruby. О любых нарушениях кодекса поведения можно сообщить Тейлору Отвеллу (taylor@laravel.com):

  • Участники будут терпимо относиться к противоположным взглядам.
  • Участники должны гарантировать, что их язык и действия не содержат личных нападок и пренебрежительных личных замечаний.
  • Толкуя слова и действия других, участники всегда должны исходить из добрых намерений.
  • Не допускается поведение, которое можно обоснованно считать преследованием.