---
title: "Come sfruttare gli script Composer per automatizzare il workflow PHP/Laravel"
date: 2025-10-24
lang: it
translationKey: how-to-use-composer-scripts-to-automate-your-php-laravel-workflow
tags: [Composer, PHP, Laravel]
description: "Definisci script personalizzati in Composer per automatizzare il tuo workflow PHP/Laravel"
---

Molti sviluppatori PHP/Laravel usano [Composer](https://getcomposer.org/) solo per installare dipendenze, ma pochi
sfruttano i vantaggi offerti dagli **script Composer**.
Gli script permettono di automatizzare task ricorrenti come test, analisi statica del codice, refactoring o setup
iniziale del progetto, semplificando il workflow e riducendo errori.   
Laravel stesso ne definisce alcuni, in modo da semplificare la configurazione del progetto o l'esecuzione di determinati
task.

## Cos'è uno script Composer

Nella sezione `scripts` di un file `composer.json` è possibile definire script personalizzati. Ad esempio:

```json showLineNumbers
{
  "scripts": {
    "test": "XDEBUG_MODE=off ./vendor/bin/pest --parallel"
  }
}
```

Dopo aver definito lo script `test`, se da shell esegui

```shell
composer test
```

verranno eseguiti i test (unit, feature, ecc.) del progetto, in questo caso utilizzando [Pest](https://pestphp.com/), in
parallelo e disabilitando XDebug (che nel mio ambiente locale è sempre attivo - viceverse, potresti tenerlo sempre
disattivato e abilitarlo solo all'occorrenza).

## Perché usare gli script Composer?

I vantaggi sono molteplici:

* ✅ consistenza: tutti i membri del *team* di sviluppo usano gli stessi comandi
* ⚙️ automazione: niente più comandi lunghi, dimenticati o con parametri errati
* 🧩 integrazione CI/CD: gli script si integrano facilmente nelle pipeline di GitHub Actions, GitLab CI, ecc.
* 💡 pulizia del progetto: evita di aggiungere al repository file shell duplicati e mantiene la configurazione nel
  `composer.json`

## Consigli pratici

* per i **nomi degli script**, non usare nomi di librerie, prodotti o tecnologie, ma termini che rappresentino il
  compito che si vuole eseguire. Il motivo è presto detto: se oggi usi una libreria per eseguire quel task, domani
  potresti sostituirla con un'altra che esegue lo stesso compito (magari meglio); in quel caso, dovresti cambiare il
  nome dello script.

  Esempio:

      ❌ `composer phpunit`
      ❌ `composer pest`
      ✅ `composer test`

  Altro esempio:

      ❌ `composer rector`
      ✅ `composer refactor`

* utilizza gli stessi nomi di script in tutti i progetti PHP/Laravel, in modo da ritrovarli ovunque e poterli usare
  facilmente e con familiarità
* se un progetto non prevede ad esempio l'uso di PHPStan o di Rector, non aggiungere gli script corrispondenti al
  file `composer.json`: renderli disponibili potrebbe confondere gli altri sviluppatori
* se hai **XDebug** attivo, usa `XDEBUG_MODE=off` a inizio comando per disabilitarlo e velocizzare l'esecuzione (ad
  esempio della suite di test o dell'analisi statica)

## Esempi pratici di script utili

### Analisi statica del codice

* `analyse`

```json
"analyse": "XDEBUG_MODE=off ./vendor/bin/phpstan analyse --memory-limit 2G --ansi"
```

Esegue l'analisi statica del codice con [PHPStan](https://phpstan.org/).

* `analyse-clear-cache`

```json
"analyse-clear-cache": "./vendor/bin/phpstan clear-result-cache"
```

Elimina la cache di PHPStan (a volte si rende necessario in caso di problemi con l'analisi statica).

### Refactoring del codice

* `refactor`

```json
"refactor": "XDEBUG_MODE=off rector process --ansi",
```

Esegue il refactoring del codice tramite [Rector](https://getrector.org/).

* `refactor-dry`

```json
"refactor-dry": "XDEBUG_MODE=off rector --dry-run --ansi"
```

Esegue Rector in modalità `dry run`, senza modificare i file: mostra solo quali modifiche verranno apportate.

### Formattazione del codice

* `format`

```json
"format": "vendor/bin/pint --dirty --parallel --ansi"
```

Esegue la formattazione del codice con [Pint](https://laravel.com/docs/12.x/pint) solo sui file modificati e in
parallelo.

### Test e code coverage

* `test`

```json
"test": "XDEBUG_MODE=off ./vendor/bin/pest --parallel --bail --colors=always"
```

Esegue i test con [Pest](https://pestphp.com/). I test vengono eseguiti in parallelo e se uno fallisce, il resto viene
interrotto.

* `test-architecture`

```json
"test-architecture": "XDEBUG_MODE=off ./vendor/bin/pest --parallel --bail --group=architectural --colors=always"
```

Esegue solo gli [architecture test](https://pestphp.com/docs/arch-testing) con [Pest](https://pestphp.com/).

* `test-coverage`

```json
"test-coverage": "php -d memory_limit=-1 ./vendor/bin/pest --coverage --min=80"
```

Esegue i test con *code coverage* e mostra il report. Se la *coverage* è inferiore all'80%, il comando fallisce.

* `type-coverage`

```json
"type-coverage": "XDEBUG_MODE=off ./vendor/bin/pest --type-coverage"
```

Esegue la [type coverage](https://pestphp.com/docs/type-coverage) con [Pest](https://pestphp.com/) per segnalare in
quali file sia possibile tipizzare parametri e valori di ritorno.

## Per concludere

Gli script Composer sono un modo semplice ma potente per standardizzare e velocizzare lo sviluppo in PHP e Laravel.
Inizia definendo pochi comandi chiave e vedrai subito la differenza nel tuo flusso di lavoro quotidiano.

Aiuteranno anche gli altri sviluppatori nel tuo team e forniranno un metodo standardizzato per eseguire i task
necessari.

Quelli sopra riportati sono quelli che utilizzo più frequentemente; definiscili in base alle tue esigenze e a quelle del
tuo team.