Questa pagina è tradotta dalla documentazione inglese. Comandi, identificatori ed esempi restano invariati. Runtime 7.24.4 · SDK 2.6.7. Testo inglese

Supporto nativo di TypeScript

Stato: Attivo nei sorgenti; rilascio del runtime impacchettato in attesa Ambito: toolchain dei sorgenti e servizio di linguaggio allo stato attuale Ultima revisione: 2026-09-14 Responsabile: responsabili di AX Code

AX Code usa il compilatore ufficiale TypeScript 7.0.2 basato su Go per i controlli del workspace, l’emissione dell’SDK e il language server JavaScript/TypeScript integrato. Il language server esegue direttamente l’eseguibile nativo distribuito con --lsp --stdio. Non invoca un runner di registry e non scarica una versione fluttuante del language server. Per usare AX Code non serve una toolchain Go.

Installa le dipendenze con pnpm install, incluse quelle facoltative. Il compilatore nativo ha bisogno del pacchetto OS/CPU corrispondente. Le build autonome preparano e verificano quel pacchetto prima della consegna. Un binario mancante o non corrispondente produce un errore azionabile, invece di avviare in silenzio un server JavaScript.

Compatibilità dell'API del compilatore

Il workspace fissa @typescript/native a npm:typescript@7.0.2 e mantiene typescript come alias di npm:@typescript/typescript6@6.0.2 per gli strumenti che importano l’API del compilatore JavaScript legacy. I controlli di tipo e l’emissione dell’SDK usano il compilatore nativo. L’API di compatibilità non è il language server predefinito.

Gli strumenti dei framework per Vue, Svelte e Astro usano la propria integrazione di server; la compatibilità della libreria TypeScript non stabilisce il supporto dei plugin del compilatore. La trasformazione JSX di SolidJS continua attraverso Babel. I test di runtime e gli artefatti emessi devono superare i controlli in modo indipendente da un typecheck riuscito.

Diagnostica e memoria

TypeScript nativo usa la diagnostica pull. AX Code la richiede quando un chiamante chiede di attendere la diagnostica o raccoglie l’inventario diagnostico. Sincronizzare un file da solo non attende il controllo dei tipi. Le modifiche invalidano i risultati in cache dipendenti; gli inventari stantii, in attesa o falliti sono riportati come parziali o degradati dall’API di diagnostica aggregata. Un pull riuscito aggiorna quel file. Le richieste di aggiornamento del server marcano i risultati in cache come stantii; la richiesta diagnostica successiva li aggiorna su richiesta. Il traffico di fondo del server non rinnova la vita di inattività. Le modifiche ai file possono ancora aggiornare in background i documenti richiesti in precedenza. L’API dei record grezzi aggiorna i risultati stantii entro un budget di raccolta limitato e rifiuta gli inventari incompleti; gli strumenti di modifica dichiarano questa condizione senza perdere la modifica del file riuscita. Gli altri language server conservano il comportamento esistente di diagnostica push.

Le attese diagnostiche esplicite sovrapposte per lo stesso file condividono una richiesta solo dentro la stessa generazione di workspace. Le richieste sequenziali aggiornano comunque; un cambio di workspace impedisce il riuso di una richiesta più vecchia ancora in corso. Gli aggiornamenti di fondo e di inventario ricontrollano la freschezza dopo aver atteso il lock del documento.

Le cancellazioni e gli spostamenti di patch riusciti chiudono i documenti sorgente rimossi nel servizio di linguaggio. Le transazioni di patch fallite conservano lo stato dei documenti. La pulizia ha una scadenza condivisa di due secondi e salta i percorsi ricreati da un’operazione successiva nella stessa patch. Una pulizia incompleta viene dichiarata senza annullare le modifiche salvate. Se la consegna al server va in timeout, la diagnostica resta incompleta finché quel client non si riavvia.

I language server inattivi vengono recuperati dopo 30 minuti nel profilo di memoria normale, oppure dopo cinque minuti con AX_CODE_MEMORY_PROFILE=low. Il recupero gira sull’intervallo esistente di controllo di salute di un minuto e attende che le richieste attive e in coda si assestino. I server si riavviano su richiesta. AX_CODE_LSP_IDLE_MS sostituisce la durata di inattività in millisecondi; 0 disattiva il recupero per inattività. I valori non validi usano il predefinito del profilo. Queste impostazioni non impongono un tetto di RAM del processo né un budget per l’intera macchina. Il preriscaldamento speculativo resta su adesione.

Recuperare un server scarta il suo inventario diagnostico. I risultati aggregati restano marcati come degradati finché i documenti aperti in precedenza non sono stati riaperti e controllati, o rimossi in modo esplicito. L’API dell’inventario grezzo rifiuta la copertura incompleta. Il registro di copertura è limitato a 2,000 percorsi; l’overflow resta in modo conservativo incompleto finché l’istanza del progetto non viene dismessa. Recuperare un server vuoto non perde copertura. Gli strumenti di modifica preservano le modifiche salvate e dichiarano che la diagnostica è incompleta. Usa un controllo dei tipi dell’intero progetto per stabilire se il progetto è pulito.

La compilazione nativa non garantisce una particolare riduzione della memoria residente. Confronta lo stesso progetto, gli stessi documenti aperti, le stesse richieste e l’RSS dell’albero dei processi prima di affermare qualcosa sulla memoria.

Sostituzione esplicita del server

Una configurazione lsp.typescript.command attendibile esistente sostituisce ancora il server nativo integrato. Per un server legacy, installa e fissa nel progetto il server e l’SDK TypeScript compatibile, poi imposta command su quell’eseguibile installato con --stdio. Evita i comandi npx non fissati. La sostituzione è esplicita; AX Code non torna in automatico al ripiego quando il compilatore nativo non è disponibile.

A monte: annuncio di TypeScript 7.

Compatibilità dei documenti salvati di TypeScript 7.0.2

Il server nativo 7.0.2 può restituire un’istantanea diagnostica precedente quando il traffico di osservazione dei file si sovrappone alle modifiche salvate. AX Code chiude e riapre i documenti cambiati per quella versione esatta del server prima di richiedere la diagnostica. Una query di documento limitata scarica la chiusura differita prima della riapertura; le altre query attendono questa sostituzione. Questo invia l’intero documento cambiato; i documenti invariati riusano ancora le richieste sovrapposte. Le altre versioni del server conservano la modalità di sincronizzazione negoziata. Una sostituzione interrotta resta incompleta finché il language server non si riavvia.