Come contribuire

• Segnalazioni di bug
• Domande di Supporto
• Discussione sullo Sviluppo Core
• Quale Branch Scegliere?
• Asset Compilati
• Vulnerabilità di sicurezza
• Stile di Codifica
• Codice di Condotta

Segnalazioni di bug

Per favorire una collaborazione attiva, Laravel incoraggia fortemente le pull request, non solo le segnalazioni di bug. Le pull request saranno revisionate solo quando contrassegnate come "pronte per la revisione" (non nello stato di "bozza") e tutti i test per le nuove funzionalità saranno passati. Le pull request inattive lasciate in stato di "bozza" saranno chiuse dopo alcuni giorni.

Tuttavia, se invii una segnalazione di bug, questa dovrebbe contenere un titolo e una descrizione chiara del problema. Dovresti includere anche quante più informazioni rilevanti possibile e un esempio di codice che dimostri il problema. L’obiettivo di una segnalazione di bug è rendere facile per te stesso – e per gli altri – replicare il bug e sviluppare una soluzione.

Ricorda, le segnalazioni di bug vengono create nella speranza che altri con lo stesso problema possano collaborare con te per risolverlo. Non aspettarti che la segnalazione di bug riceva automaticamente attenzione o che altri intervengano per risolverla. Creare una segnalazione di bug serve ad aiutare innanzitutto te stesso e altri ad iniziare il percorso per risolvere il problema. Se vuoi contribuire, puoi aiutare correggendo qualsiasi bug elencato nei nostri tracker. Devi essere autenticato su GitHub per visualizzare tutti le issue di Laravel.

Se noti un DocBlock improprio, avvisi PHPStan o IDE durante l’uso di Laravel, non creare un’issue su GitHub. Apri, invece, una pull request per risolvere il problema.

Il codice sorgente di Laravel è gestito su GitHub e ci sono repository per ciascuno dei progetti Laravel:

• Laravel Application
• Laravel Art
• Laravel Breeze
• Laravel Documentation
• Laravel Dusk
• Laravel Cashier Stripe
• Laravel Cashier Paddle
• Laravel Echo
• Laravel Envoy
• Laravel Folio
• Laravel Framework
• Laravel Homestead (Build Scripts)
• Laravel Horizon
• Laravel Jetstream
• Laravel Passport
• Laravel Pennant
• Laravel Pint
• Laravel Prompts
• Laravel Reverb
• Laravel Sail
• Laravel Sanctum
• Laravel Scout
• Laravel Socialite
• Laravel Telescope
• Laravel Website

Domande di Supporto

I tracker delle issue di GitHub di Laravel non sono destinati a fornire aiuto o supporto per Laravel. Utilizza invece uno dei seguenti canali:

• GitHub Discussions
• Laracasts Forums
• Laravel.io Forums
• StackOverflow
• Discord
• Larachat
• IRC

Discussione sullo Sviluppo Core

Puoi proporre nuove funzionalità o miglioramenti del comportamento esistente di Laravel nel GitHub discussion board del repository del framework Laravel. Se proponi una nuova funzionalità, sii disposto a implementare almeno parte del codice necessario per completarla.

Le discussioni informali riguardanti bug, nuove funzionalità e l’implementazione di funzionalità esistenti avvengono nel canale #internals del Laravel Discord server. Taylor Otwell, il manutentore di Laravel, è generalmente presente nel canale nei giorni feriali dalle 8:00 alle 17:00 (UTC-06:00 o America/Chicago) e in modo sporadico in altri momenti.

Quale Branch Scegliere?

Tutte le correzioni di bug devono essere inviate all’ultima versione che riceve correzioni (attualmente 11.x). Le correzioni di bug non devono mai essere inviate al branch master a meno che non correggano funzionalità presenti solo nella prossima versione.

Le funzionalità minor che sono completamente retrocompatibili con la versione attuale possono essere inviate all’ultimo branch stabile (attualmente 11.x).

Le nuove funzionalità major o quelle con cambiamenti significativi devono sempre essere inviate al branch master, che contiene la prossima release.

Asset Compilati

Se stai inviando una modifica che influenzerà un file compilato, come la maggior parte dei file in resources/css o resources/js del repository laravel/laravel, non versionare i file compilati. A causa delle loro dimensioni, non possono essere revisionati da un manutentore. Per evitare problemi di sicurezza, tutti i file compilati saranno generati e versionati solo dai manutentori di Laravel.

Vulnerabilità di sicurezza

Se scopri una vulnerabilità in Laravel, invia un’email a Taylor Otwell all’indirizzo taylor@laravel.com. Tutte le vulnerabilità saranno risolte il prima possibile.

Stile di Codifica

Laravel segue lo standard di codifica PSR-2 e lo standard di autoloading PSR-4.

PHPDoc

Di seguito è riportato un esempio di blocco di documentazione valido di Laravel. Nota che l’attributo @param è seguito da due spazi, dal tipo dell’argomento, altri due spazi e infine dal nome della variabile:

/**
 * 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)
{
    // ...
}

Quando gli attributi @param o @return sono ridondanti grazie all’uso di tipi nativi, possono essere rimossi:

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

Tuttavia, quando il tipo nativo è generico, specifica il tipo generico utilizzando gli attributi @param o @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

Non preoccuparti se lo stile del tuo codice non è perfetto! StyleCI applicherà automaticamente eventuali correzioni di stile al repository di Laravel dopo che le pull request saranno state unite. Questo ci permette di concentrarci sul contenuto del contributo e non sullo stile del codice.

Codice di Condotta

Il codice di condotta di Laravel deriva da quello di Ruby. Eventuali violazioni possono essere segnalate a Taylor Otwell (taylor@laravel.com):

• I partecipanti saranno tolleranti verso opinioni diverse.
• I partecipanti devono assicurarsi che il loro linguaggio e le loro azioni siano privi di attacchi personali e commenti denigratori.
• Quando interpretano le parole e le azioni degli altri, i partecipanti dovrebbero sempre presumere buone intenzioni.
• Comportamenti che possono essere ragionevolmente considerati molestia non saranno tollerati.