Medusa 2.19 è disponibile: cosa cambia davvero per il Suo store

Medusa 2.19.0 è stata rilasciata il 13 agosto 2026 ed è ora la versione attuale della piattaforma. Il titolo ufficiale del rilascio — “Vite v7 Update, Inventory Export, Custom Fulfillment Addresses” — riassume i punti principali: un importante aggiornamento infrastrutturale e alcune funzionalità che il Suo team operativo userà ogni settimana.

Se gestisce un'attività e-commerce su Medusa, probabilmente non ha bisogno di leggere il changelog riga per riga. Le servono tre informazioni: cosa ottiene il Suo team, cosa potrebbe non funzionare più e cosa chiedere agli sviluppatori prima di intervenire in produzione. Questo articolo risponde a queste domande.

In sintesi

Novità utili per le operations. Ora può esportare l'inventario in CSV, spedire a indirizzi diversi da quello di spedizione del cliente e decidere se notificare il cliente via email quando modifica un ordine. Tutte e tre eliminano soluzioni manuali che i team di store hanno dovuto adottare finora.

Novità per IT e sicurezza. Medusa ora include un provider di autenticazione OIDC generico, che consente di integrare i login del personale con il Suo sistema di identità esistente.

Un aspetto da pianificare. Questo rilascio introduce tre cambiamenti che possono interrompere la compatibilità, oltre a nuovi requisiti minimi sia per l'ambiente di hosting sia per i browser usati dal personale sulla dashboard amministrativa. Nulla di critico, ma meglio non scoprirlo un venerdì pomeriggio.

La novità che i responsabili di store noteranno per prima

Partiamo da qui, perché è il cambiamento che più probabilmente genererà domande già dal primo giorno.

Medusa 2.19 aggiorna la dashboard amministrativa a Vite 7.3.6 e React Router 7.18.2 — versioni moderne degli strumenti su cui si basa la dashboard. Una conseguenza di questo aggiornamento è che le versioni minime dei browser sono aumentate:

Per la maggior parte dei team non cambia nulla — chi usa un browser che si aggiorna automaticamente è già oltre queste versioni. Ma la questione è rilevante in due casi frequenti nel retail e nel wholesale:

• Macchine condivise o bloccate. Terminali di magazzino, computer vicino al POS in negozio e qualsiasi macchina su cui l'IT ha bloccato la versione del browser.
• Mac più datati. Safari 16 richiede almeno macOS Big Sur. Un responsabile di store con un Mac troppo vecchio dovrà passare a Chrome o Firefox, oppure sostituire la macchina.

Prima di procedere con l’aggiornamento, conviene dedicare cinque minuti a una verifica: quali dispositivi usa effettivamente il Suo team per accedere all’area amministrativa e quali browser sono installati? Individuare ora una postazione obsoleta costa molto meno che scoprirlo quando qualcuno non riesce a gestire un reso.

Lo stesso aggiornamento alza anche il requisito Node.js per l’ambiente server a ^20.19.0, ^22.12.0 o una versione LTS più recente. Le versioni Node 20.0–20.18 e 22.0–22.11 non sono più supportate. Non è un aspetto che deve gestire direttamente, ma è una domanda da porre a chi si occupa dell’hosting: stiamo usando una versione supportata di Node?

Esportazione dell’inventario finalmente disponibile

Se ha mai avuto bisogno dei livelli di stock attuali in un foglio di calcolo — per un fornitore, un inventario, una sessione di pianificazione o semplicemente per il commercialista — conosce la procedura: chiedere a uno sviluppatore di eseguire una query o copiare manualmente i dati dalla dashboard.

Medusa 2.19 introduce l’esportazione degli articoli di inventario in formato CSV, sia dalla dashboard amministrativa sia tramite API. Segue lo stesso schema già usato da Medusa per l’esportazione di prodotti e ordini, quindi chi ha già utilizzato queste funzioni troverà il processo familiare.

Si tratta di una funzione semplice che riduce in modo significativo la dipendenza del team operativo da quello tecnico. Riconciliazione di stock, reportistica per fornitori e pianificazione dell’inventario diventano attività autonome.

Le spedizioni possono ora essere inviate a un indirizzo diverso

Uno scenario che prima o poi ogni store in crescita affronta: un cliente ordina un articolo che deve essere spedito da una sede diversa dal Suo magazzino — un fornitore, un produttore, un partner logistico — o deve arrivare a una destinazione diversa da quella indicata nell’ordine.

Fino ad ora, questo richiedeva soluzioni alternative. Con la versione 2.19, quando crea una spedizione può indicare un indirizzo di consegna diverso da quello dell’ordine e trasmettere dati aggiuntivi al fornitore logistico.

Le applicazioni pratiche:

• Drop-shipping. Invia una spedizione all’indirizzo di un fornitore senza modificare l’ordine del cliente.
• Gestione multi-magazzino e 3PL. Fornisce al partner logistico l’indirizzo e le istruzioni esatte per la spedizione.
• Requisiti specifici del fornitore. Il campo additional_data consente di trasmettere metadati — numeri di riferimento, istruzioni di gestione, codici account — senza dover modificare il codice ogni volta che un partner richiede un nuovo campo.

Se una parte del Suo catalogo viene spedita da sedi esterne, questa è la funzione della 2.19 da segnalare ai Suoi sviluppatori.

Controllo sulle email relative alle modifiche ordine

Le modifiche agli ordini sono normali in assistenza clienti: un cliente chiama per aggiungere un articolo, cambiare una taglia o rimuovere qualcosa prima della spedizione. In passato, non era possibile regolare il comportamento delle notifiche relative a queste modifiche.

I flussi di modifica ordine ora rispettano le preferenze di notifica: quando il Suo team modifica un ordine, può scegliere se inviare o meno una notifica al cliente — in linea con i controlli già previsti da Medusa per altre operazioni sugli ordini.

Il valore qui sta nella possibilità di scegliere. Alcune modifiche richiedono effettivamente una comunicazione — il cliente deve sapere se un articolo esaurito viene rimosso. Altre sono correzioni interne che, se notificate, generano solo confusione e ticket di supporto. Dare al team il controllo su questo aspetto riduce silenziosamente il volume di contatti.

Accesso staff tramite identity provider aziendale

Medusa 2.19 introduce un provider OIDC generico per l’autenticazione. OIDC (OpenID Connect) è lo standard aperto adottato dalla maggior parte dei sistemi di identità aziendali, il che significa che ora Medusa può essere integrato con lo stesso login già usato dal Suo team per altri servizi.

Perché un CEO e-commerce dovrebbe interessarsi a una voce che sembra solo infrastruttura:

• L’offboarding è realmente efficace. Quando una persona lascia l’azienda, la revoca dell’account centrale elimina anche l’accesso all’admin. Non serve più cercare login orfani con permessi di rimborso ordini.
• La policy di sicurezza aziendale si applica anche qui. MFA obbligatoria, scadenza sessioni, regole di accesso condizionato — tutto gestito centralmente, senza dover replicare le regole su ogni sistema.
• Le verifiche di sicurezza sono più semplici. «Come controllate l’accesso all’area amministrativa?» è una domanda più facile quando la risposta è «come per tutti gli altri sistemi aziendali».

Questa è una base tecnica, non un’integrazione già pronta — il collegamento con il Suo identity provider specifico richiede lavoro da parte degli sviluppatori. Ma era il tassello necessario, ora disponibile.

La ricerca è stata spostata sul backend

L’autenticazione non è l’unico aspetto infrastrutturale rivisto nella 2.19. Cambia anche il modo in cui si cercano dati nell’admin — la barra di ricerca che il Suo team usa decine di volte al giorno.

La 2.19 introduce un modulo di ricerca con endpoint backend dedicato e un DSL — un linguaggio strutturato per definire la costruzione degli indici di ricerca — e la ricerca nell’admin ora utilizza questo endpoint backend.

Medusa non ha pubblicato dati sulle prestazioni, quindi diffidi di chi fa promesse specifiche sulla velocità. Quello che cambia strutturalmente è che la ricerca ora avviene lato server tramite un modulo dedicato, invece che come in passato: è l’architettura indicata se il Suo catalogo è ampio o in crescita. Se il Suo team ha avuto problemi con la ricerca nell’admin su cataloghi grandi, questa versione cambia la base tecnica — vale la pena testare dopo l’aggiornamento.

Le tre modifiche breaking, in termini chiari

Le note di rilascio segnalano tre modifiche breaking. Ecco cosa comportano concretamente.

1. Aggiornamento a Vite 7 e React Router 7. Già trattato sopra — aumentano i requisiti per browser e Node. Il rischio riguarda eventuali estensioni personalizzate della dashboard admin: potrebbero richiedere un aggiornamento. Chieda ai Suoi sviluppatori se ne avete.

2. Rimozione di quattro metodi per le opzioni prodotto dalla JS SDK. Sono stati rimossi i metodi per creare, aggiornare, recuperare ed eliminare opzioni prodotto; ora si usa il metodo generale di aggiornamento prodotto. Questo impatta solo codice personalizzato o integrazioni che usavano quei metodi specifici. È un cambiamento mirato, ma se ha una sincronizzazione PIM o uno strumento bulk, va verificato.

3. Totali di carrello e ordine ora inclusi di default. Prima, richiedere tutti i campi di un carrello o ordine escludeva i totali calcolati. Ora sono inclusi. Il comportamento di default è più intuitivo, ma significa che queste richieste fanno più lavoro di prima. Il consiglio di Medusa è di richiedere solo i campi necessari, non tutto: se il Suo storefront o un’integrazione recupera carrelli e ordini in modo esteso, valuti l’impatto sulle prestazioni dopo l’aggiornamento.

Cosa chiedere al Suo team prima di aggiornare

Non è necessario eseguire l'aggiornamento. È invece fondamentale che vengano poste le domande giuste. Ecco quelle che vale la pena mettere per iscritto:

1. Stiamo utilizzando una versione di Node supportata (^20.19.0, ^22.12.0 o una LTS più recente)? In caso contrario, qual è il piano?
2. Quali browser utilizza il team per accedere all'admin? Qualcuno è inferiore a Chrome 107 / Edge 107 / Firefox 104 / Safari 16?
3. Abbiamo sviluppato estensioni personalizzate per la dashboard admin? Sono state testate con Vite 7 e React Router 7?
4. Qualche parte del nostro codice utilizza i metodi SDK product-option rimossi?
5. Richiediamo tutti i campi su carrelli o ordini in qualche punto? Se sì, come incide la modifica dei totali sui tempi di risposta?
6. Abbiamo testato tutto su un ambiente di staging che rispecchia la produzione, comprese le migrazioni del database?
7. Qual è il nostro piano di rollback se dovesse emergere un problema dopo il rilascio in produzione?

Quindi, conviene aggiornare?

Sì, con una tempistica ragionevole.

Le funzionalità operative introdotte nella 2.19 servono a eliminare attriti, non ad aggiungere complessità: esportazione inventario, indirizzi di fulfillment flessibili e controllo delle notifiche sono strumenti che il team inizierà a usare subito. Il provider OIDC diventa strategico quando il controllo degli accessi e gli audit diventano esigenze concrete — una fase che, per la maggior parte delle aziende e-commerce in crescita, arriva prima del previsto.

Le modifiche breaking sono circoscritte e ben documentate. Il rischio reale non è che l'upgrade fallisca, ma che nessuno abbia verificato il browser sul terminale del magazzino, o che un'estensione admin personalizzata, trascurata da mesi, smetta improvvisamente di funzionare.

Esegua tutto su staging, risponda alle sette domande sopra, e pianifichi l'aggiornamento in produzione in una mattina con sviluppatori presenti e basso volume ordini. Questo è tutto il piano.

Gestisce uno store su Medusa?

Gestiamo lo sviluppo Medusa per store in cui il passaggio su staging, la revisione delle estensioni e la finestra di upgrade sono responsabilità di qualcuno — nostra. È la stessa disciplina applicata a progetti come lo storefront multi-regione di AURA&CO su Medusa 2.18. Se preferisce affidare a terzi l'upgrade alla 2.19, ci contatti.