Categoria
Articoli tecnici organizzati per gruppo funzionale.
L'importazione diretta di moduli da URL remoti ('https://...') è disabilitata per default per ragioni di sicurezza; richiede il flag sperimentale '--experimental-network-imports'.
L'uso di alias interni con prefisso '#name' (subpath imports) fallisce se il mapping non è dichiarato esplicitamente nella sezione '"imports"' del file package.json del progetto.
Compare quando si tenta di importare un file interno di una libreria ('import x from "pkg/lib/util.js"') ma il package.json dell'autore definisce una mappa restrittiva 'exports' che incapsula i file interni vietando l'accesso diretto.
Si verifica quando un file CommonJS (.cjs o progetto senza "type": "module") tenta di importare una libreria pubblicata solo come ES Module (es. node-fetch v3, chalk v5) tramite 'require()'; si risolve convertendo il progetto a ESM o usando 'await import()' dinamico.
Il runtime Node.js nativo esegue solo file JavaScript (.js, .mjs, .cjs); eseguire direttamente file TypeScript (.ts) o JSX senza loader o bundler (come tsx, ts-node o flag '--experimental-strip-types' da Node 22+) scatena questo errore.
A differenza di CommonJS che risolveva automaticamente 'index.js' all'interno di una directory, la specifica ES Modules di Node.js vieta l'import di directory ('import x from "./models"'); richiede di specificare il file completo ('./models/index.js').
Su Windows, passare un percorso assoluto con backslash ('C:\path\file.js') a un'istruzione di importazione ESM fallisce perché il loader richiede uno schema URL ('file:///C:/path/file.js') o l'uso di 'pathToFileURL()' del modulo url nativo.
L'esecuzione di codice tramite 'vm.runInContext()' o 'new vm.Script()' che include chiamate ad 'import()' dinamico fallisce a meno di definire esplicitamente l'opzione 'importModuleDynamically'.