TypeScript Interface vs Type — Differenze Pratiche per Non Sbagliare

Ti è mai capitato di guardare un codice TypeScript e chiederti: «Ma qui usano interface o type? Perché?» — e la risposta non era mai chiara. In tanti progetti che ci arrivano come consulenti — da startup a medie aziende metalmeccaniche — vediamo file pieni di dichiarazioni miste, dove type e interface si rincorrono senza una logica. Il risultato? Codice meno prevedibile, refactoring più lenti e team confusi.

Non è colpa tua: TypeScript stesso ha mantenuto a lungo le due strade parallele, e la scelta sembra spesso una questione di religione. Ma non lo è. C’è una differenza tecnica sostanziale che, se capita, ti fa risparmiare ore di debugging e rende il tuo sistema più robusto. Noi, di Meteora Web, lavoriamo quotidianamente con Laravel, Vue e TypeScript puro su piattaforme business-critical: la differenza tra interface e type è pratica, non accademica. Vediamola insieme.

Interface vs Type in TypeScript — Qual è la Differenza Strutturale?

Partiamo da zero: sia interface che type servono a descrivere la forma di un oggetto. La differenza chiave è che una interface può essere dichiarata più volte e TypeScript le unisce automaticamente (declaration merging). Un type alias, invece, è definitivo: una volta definito, non si può più estendere nella stessa dichiarazione.

Declaration merging — il superpotere delle interface

Esempio pratico: immagina di lavorare su un'applicazione che usa una libreria di terze parti. Quella libreria esporta un tipo User. Tu hai bisogno di aggiungere una proprietà phone lato tuo, senza toccare la libreria originale. Con un’interface puoi farlo:

// Libreria esterna
interface User {
  id: number;
  name: string;
}

// Il tuo file di estensione
interface User {
  phone: string;
}

// Adesso User ha id, name e phone
const u: User = { id: 1, name: 'Mario', phone: '333123456' };

Con un type non puoi. Se provi a dichiarare due tipi con lo stesso nome, TypeScript lancia errore. Questa è la regola d’oro: se hai bisogno di estendibilità aperta, scegli interface. Se vuoi chiudere la definizione e garantire che nessuno possa alterarla, scegli type.

Quando Usare Type Alias Invece di Interface in TypeScript?

Ci sono casi in cui type è l’unica opzione possibile. Ecco i più frequenti:

Union e Intersection types

Un type può rappresentare l’unione di più forme, un’interface no.

type Status = 'attivo' | 'inattivo' | 'sospeso';
type Result = { id: number } & { status: Status }; // intersection
type Shape = Circle | Square; // union

Un’interface può fare l’intersection usando l’extends per oggetti, ma non può modellare direttamente una union. Se ti serve un tipo che sia “o questo o quello”, devi usare type.

Tuple e tipi primitivi

Type alias può dare un nome a tuple, primitive o a tipi complessi come stringhe letterali:

type Pair = [number, string];
type MyString = string;
type Direction = 'nord' | 'sud' | 'est' | 'ovest';

Le interface sono pensate per oggetti (e classi). Se non stai descrivendo un oggetto, usa type.

TypeScript Interface vs Type — Quale Scegliere per Estendibilità e Manutenzione?

Nei progetti reali, la manutenzione a lungo termine conta più del risparmio di due righe oggi. Noi di Meteora Web adottiamo una regola empirica:

• Per oggetti di dominio (User, Order, Product) → interface – perché potranno essere estese da contesti diversi (API, DB, frontend).
• Per configurazioni, union, tuple, tipi derivati → type – perché sono definizioni chiuse e precise.
• Per le props di componenti React/Vue → entrambi vanno bene, ma l’interface è più comune nella documentazione ufficiale. Se il componente è esportato da una libreria, interface permette agli utenti di estendere le props con declaration merging.

Attenzione: non è una guerra fratricida. Si possono mettere insieme benissimo. Spesso in un progetto trovi:

interface BaseEntity {
  id: number;
  createdAt: Date;
}

type UserStatus = 'active' | 'inactive';

interface User extends BaseEntity {
  name: string;
  status: UserStatus;
}

Perfetto: interface per la struttura base, type per il valore ristretto. La sintassi extends funziona con entrambi: interface User extends BaseEntity o type User = BaseEntity & { ... }. La differenza è che extends su un’interface è più performante in TypeScript per i controlli di compatibilità (cross-file).

Quali Sono gli Errori Comuni con Interface e Type in TypeScript?

Vediamo i due problemi che incontriamo più spesso quando analizziamo il codice dei clienti:

Errore 1: Usare type dove servirebbe un declaration merging

Un’azienda di logistica ci ha portato un progetto con una dozzina di file che importavano un type Shipment e volevano aggiungere un campo trackingUrl senza modificare il file originale. Con type non potevano. Hanno dovuto rifattorizzare tutto. Con interface sarebbe bastata una riga.

Errore 2: Usare interface per union e non riuscire a compilare

Un cliente ci ha chiamato dicendo: «TypeScript mi dice che interface non può essere un’unione». Esatto. Se hai bisogno di un’unione, usa type. È un errore comune soprattutto a chi arriva da linguaggi OOP classici.

Errore 3: Mischiare senza criterio

Non c’è niente di male a usare entrambi, ma se ogni file adotta una convenzione diversa, la leggibilità crolla. Fissate una regola di team e annotatela nel linter. Noi, per esempio, abbiamo una regola ESLint personalizzata che vieta type per oggetti semplici (salvo eccezioni documentate).

Performance e Compilazione — Interface vs Type, C’è Differenza?

Domanda legittima. In fase di compilazione, interface è leggermente più “leggera” per il compilatore TypeScript perché non genera alias di tipo quando esportata. Inoltre, il controllo di compatibilità strutturale (duck typing) è leggermente più veloce con interface. Ma siamo nell’ordine dei microsecondi. Non è un motivo per preferire l’una all’altra; la scelta deve basarsi sulla semantica del dominio, non sulle performance di compilazione.

Cosa Fare Adesso

Non serve rivoluzionare tutto il codice. Ecco tre azioni concrete:

1. Rivedi la convenzione del tuo team. Decidete insieme una policy semplice: “Interface per oggetti di dominio, type per union, tuple e tipi letterali”. Scrivetela in un archi di progetto README.
2. Aggiungi una regola ESLint per forzare la scelta. Usa @typescript-eslint/consistent-type-definitions per richiedere interface sugli oggetti. Lo trovi nella documentazione ufficiale: typescript-eslint/consistent-type-definitions.
3. Controlla i tuoi file più critici (entità, DTO, risposte API) e converti i type alias in interface se non usano union. Ti semplificherà la vita quando un collega o un’API di terze parti dovrà estendere quelle definizioni.

Se vuoi approfondire le basi di TypeScript prima di questa differenza, leggi la nostra guida pillar su TypeScript, dove partiamo da zero e arriviamo fino ai pattern avanzati.