Comandi per l’aggiornamento delle dipendenze

Quando si lavora con Laravel, ci si trova subito davanti a due cartelle molto voluminose: node_modules e vendor. Non sono semplici directory: rappresentano l’ecosistema di librerie che permette al progetto di funzionare in modo stabile, sicuro e scalabile.

node_modules: l’ecosistema JavaScript del progetto

La cartella node_modules contiene tutte le dipendenze JavaScript installate tramite npm o Yarn. In un progetto Laravel serve principalmente per:

• compilare e ottimizzare gli asset frontend (CSS, JS);
• utilizzare strumenti moderni come Vite, TailwindCSS, Vue, React;
• gestire workflow di sviluppo come hot reload, minificazione, transpiling.
• È molto pesante e non va mai versionata (infatti è esclusa dal .gitignore).

In pratica, tutto ciò che riguarda la parte frontend passa da qui.

vendor: il cuore PHP del framework

La cartella vendor contiene tutte le dipendenze PHP installate tramite Composer, tra cui:

• il codice sorgente del framework Laravel;
• librerie di terze parti (per logging, caching, database, sicurezza…);
• pacchetti aggiuntivi installati nel progetto;
• il sistema di autoloading PSR-4.
• Anche questa cartella non va versionata.

È la base che permette a Laravel di funzionare correttamente e in modo modulare.

Comandi per l’aggiornamento della directory node_modules in sviluppo

In ambiente di sviluppo si possono eseguire i seguenti comandi:

comando	descrizione	legge	scrive
npm install pacchetto	aggiunge un pacchetto a node_modules		package.json package-lock.json libreria di codice
npm outdated	fornisce una lista dei pacchetti obsoleti	package.json
npm update	in base al file package.json ricerca le versioni più recenti e le installa (non eseguire mai in produzione, perché può introdurre crash)	package.json	package-lock.json libreria di codice
npm ci oppure npm install	installa le librerie indicate nel file package-lock.json	package-lock.json	libreria di codice

Ricostruzione degli asset in produzione

Si presentano due diversi scenari, in base al tipo di deploy.

Scenario A: build degli asset in produzione

Se gli asset possono essere compilati sul server di produzione (avviene raramente), si esegue:

npm install
npm run build

Queste operazioni:

• ricreano node_modules;
• generano gli asset finali (di solito in public/build).

Scenario B: build degli asset in CI/CD

Molti team non installano node_modules in produzione, ma compilano gli asset prima, ad esempio in GitHub Actions, GitLab CI, Forge, Envoyer ecc.

In questo caso:

• la build produce solo i file finali (CSS/JS minificati);
• node_modules non viene mai caricato sul server.

Risultato: in produzione arrivano solo gli asset già compilati.

Comandi per l’aggiornamento della directory vendor in sviluppo

In ambiente di sviluppo si possono eseguire i seguenti comandi:

comando	descrizione	legge	scrive
composer require vendor/pacchetto	aggiunge un pacchetto a vendor		composer.json composer.lock libreria di codice
composer outdated	fornisce una lista dei pacchetti obsoleti	composer.json
composer update	in base al file composer.json ricerca le versioni più recenti e le installa (non eseguire mai in produzione, perché può introdurre crash)	composer.json	composer.lock libreria di codice
composer install	installa le librerie indicate nel file composer.lock	composer.lock	libreria di codice

Ricostruzione della cartella vendor in produzione

In produzione si esegue:

composer install --no-dev --optimize-autoloader

Questo comando:

• scarica tutte le dipendenze PHP necessarie;
• esclude i pacchetti di sviluppo (--no-dev);
• ottimizza l’autoload per migliorare le performance (--optimize-autoloader).

Risultato: la cartella vendor viene ricreata da zero in modo pulito e ottimizzato.