## Esempi rapidi```js
import { VM } from 'vm2';

const vm = new VM();
vm.run(`process.exit()`); // TypeError: process.exit is not a function

## Importante Dichiarazione di Sicurezza

**Prima di usare vm2, dovresti capire come funziona e quali sono i suoi limiti.**

vm2 tenta di isolare codice JavaScript non attendibile **all'interno dello stesso processo Node.js** della tua applicazione. Lo fa attraverso una complessa rete di [Proxy](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Proxy) che intercettano e mediano ogni interazione tra la sandbox e l'ambiente host.

### La Sfida Fondamentale

JavaScript è un linguaggio straordinariamente dinamico. Gli oggetti possono essere raggiunti tramite le catene di prototipi, i costruttori possono essere raggiunti tramite gli oggetti di errore, i simboli forniscono hook di protocollo e l'esecuzione asincrona crea finestre di temporizzazione. L'enorme numero di modi per passare da un oggetto all'altro in JavaScript rende estremamente difficile costruire una sandbox in-process a tenuta stagna.

**Siamo onesti su questa realtà:** Nonostante i nostri migliori sforzi, ricercatori e professionisti della sicurezza scoprono continuamente nuovi modi per evadere dalla sandbox di vm2. Correggiamo attivamente queste vulnerabilità man mano che vengono segnalate, ma la natura del gatto e del topo dell'isolamento in-process significa che:

1. **È probabile che in futuro vengano scoperti nuovi bypass.** Controlla i nostri [avvisi di sicurezza](https://github.com/patriksimek/vm2/security/advisories) per le vulnerabilità note.
2. **Devi mantenere vm2 aggiornato** per beneficiare delle ultime correzioni di sicurezza. Iscriviti agli avvisi di sicurezza e aggiorna tempestivamente.
3. **vm2 non dovrebbe essere la tua unica linea di difesa.** La difesa in profondità è essenziale quando si esegue codice non attendibile.

### Alternative Più Robuste

Se hai bisogno di garanzie di isolamento più forti, considera queste alternative che forniscono **un vero isolamento a livello di processo o hardware**:

| Soluzione | Approccio | Prestazioni | Compromessi |
|----------|----------|-------------|------------|
| **[isolated-vm](https://github.com/laverdet/isolated-vm)** | Isolati V8 separati (heap V8 diverso) | Veloce | In modalità manutenzione; richiede aggiornamenti manuali di V8 |
| **Processo separato / Worker** | `child_process` o thread Worker con permessi limitati | Medio | Maggiore overhead IPC; i dati devono essere serializzati |
| **Contenitori / VM** | Docker, gVisor, Firecracker | Lento | Overhead di avvio; uso intensivo di risorse |
| **Servizi gestiti** | Esecuzione di codice basata su cloud (es. AWS Lambda, Cloudflare Workers) | Variabile | Latenza di rete; dipendenza esterna |

### Quando vm2 Può Ancora Essere Appropriato

vm2 può essere adatto quando:
- Hai bisogno di una stretta integrazione con gli oggetti host e una comunicazione sincrona veloce
- Il codice non attendibile proviene da una fonte relativamente affidabile (es. strumenti interni, sistemi di plugin con autori verificati)
- Combini vm2 con altri livelli di sicurezza (isolamento di rete, restrizioni sul filesystem, limiti di risorse)
- Accetti il rischio e monitori attivamente gli aggiornamenti di sicurezza

**Se stai eseguendo codice da fonti completamente non attendibili (es. invii arbitrari da parte degli utenti), ti consigliamo vivamente di utilizzare una soluzione con garanzie di isolamento più forti.**

## Runtime

| Runtime | Stato |
|---------|--------|
| Node.js | Supportato. La sandbox è un confine di sicurezza. |
| Bun | **Sperimentale.** Compatibilità funzionale parziale — **non** è un confine di sicurezza. |

Due limitazioni separate si applicano a Bun, e nessuna implica l'altra.

**Non è un confine di sicurezza.** Il modello di minaccia di vm2, il catalogo degli attacchi in
[`docs/ATTACKS.md`](https://github.com/patriksimek/vm2/blob/main/docs/ATTACKS.md) e ogni test di regressione in `test/ghsa/`
derivano dagli interni di V8. JavaScriptCore, che Bun utilizza, ha i suoi
equivalenti, e nessuno è stato sottoposto ad audit rispetto al bridge di vm2. La suite che passa
sotto Bun dimostra compatibilità, non che la sandbox regga lì. **Non
usare vm2 su Bun per isolare codice non attendibile.**

**La compatibilità è parziale, non parità.** Un'esecuzione Bun verde copre solo i test
che vengono effettivamente eseguiti lì. `test/bun-skips.js` elenca cosa è escluso e perché,
e le lacune comportamentali note includono:

- `Buffer.from(arrayLike)` restituisce un buffer a lunghezza zero
- I metadati `filename` / `lineOffset` / `columnOffset` di `VMScript` non sono
  osservabili, perché gli oggetti CallSite di JSC non hanno metodi
- `Object.freeze` su un oggetto host congelato con un accessor non configurabile
  genera un `TypeError` di invariante proxy dove V8 non lo fa
- alcune operazioni `Buffer` attraverso il confine della sandbox sono drasticamente più lente —
  un `allocUnsafe` da 64 MB richiede oltre 400 secondi contro 1.7 su Node, abbastanza lento
  da sembrare un blocco

Tratta il supporto Bun come compatibilità best-effort per codice affidabile e controlla la
lista di esclusione prima di fare affidamento su un comportamento particolare.

## Caratteristiche

-   Esegue codice non attendibile in modo sicuro in un singolo processo con il tuo codice affiancato
-   Controllo completo sull'output della console della sandbox
-   La sandbox ha accesso limitato ai metodi del processo
-   È possibile richiedere moduli (integrati ed esterni) dalla sandbox
-   Puoi limitare l'accesso a determinati (o tutti) i moduli integrati
-   Puoi chiamare metodi in modo sicuro e scambiare dati e callback tra le sandbox
-   Mantenuto attivamente con patch per i metodi di fuga noti (vedi [Dichiarazione di Sicurezza](#importante-dichiarazione-di-sicurezza))
-   Supporto transpiler

## Come funziona

-   Utilizza il modulo VM interno per creare un contesto sicuro.
-   Utilizza [Proxy](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Proxy) per impedire la fuga dalla sandbox.
-   Sostituisce il require integrato per controllare l'accesso ai moduli.

Per un'analisi approfondita degli interni di vm2, vedi [docs/ATTACKS.md](https://github.com/patriksimek/vm2/blob/main/docs/ATTACKS.md).

## Qual è la differenza tra il modulo vm di Node e vm2?

Provalo tu stesso:```js
import { runInNewContext } from "node:vm";

runInNewContext('this.constructor.constructor("return process")().exit()');
console.log('Never gets executed.');

## Documentazione

-   [VM](#vm)
-   [NodeVM](#nodevm)
-   [VMScript](#vmscript)
-   [Gestione degli errori](#gestione-degli-errori)
-   [Debug del codice in sandbox](#debug-del-codice-in-sandbox)
-   [Oggetti di sola lettura](#oggetti-di-sola-lettura-sperimentale)
-   [Oggetti protetti](#oggetti-protetti-sperimentale)
-   [Relazioni tra sandbox](#relazioni-tra-sandbox)
-   [CLI](#cli)
-   [Modifiche dalla 2.x alla 3.x](https://github.com/patriksimek/vm2/wiki/2.x-to-3.x-changes)
-   [Documentazione 1.x e 2.x](https://github.com/patriksimek/vm2/wiki/1.x-and-2.x-docs)
-   [Contributi](https://github.com/patriksimek/vm2/wiki/Contributing)

## VM

VM è una sandbox semplice per eseguire in modo sincrono codice non attendibile senza la funzionalità `require`. Sono disponibili solo gli oggetti integrati di JavaScript e il `Buffer` di Node. Le funzioni di pianificazione (`setInterval`, `setTimeout` e `setImmediate`) non sono disponibili per impostazione predefinita.

**Opzioni:**

-   `timeout` - Timeout dello script in millisecondi. **ATTENZIONE**: Potresti voler usare questa opzione insieme a `allowAsync=false`. Inoltre, operare sugli oggetti restituiti dalla sandbox può eseguire codice arbitrario e aggirare il timeout. Si dovrebbe verificare se l'oggetto restituito è un primitivo con `typeof` e scartarlo completamente (anche registrare log o creare messaggi di errore con tale oggetto potrebbe eseguire nuovamente codice arbitrario) nel caso contrario.
-   `sandbox` - Oggetto globale della VM.
-   `compiler` - `javascript` (predefinito), `typescript`, `coffeescript` o una funzione di compilazione personalizzata. La libreria si aspetta che tu abbia il compilatore preinstallato se il valore è impostato su `typescript` o `coffeescript`. **`typescript` richiede `typescript@6` o versioni precedenti** — vedi [Compilatori](#compilatori).
-   `eval` - Se impostato su `false`, qualsiasi chiamata a `eval` o ai costruttori di funzioni (`Function`, `GeneratorFunction`, ecc.) genererà un `EvalError` (predefinito: `true`).
-   `wasm` - Se impostato su `false`, qualsiasi tentativo di compilare un modulo WebAssembly genererà un `WebAssembly.CompileError` (predefinito: `true`). Nota: `WebAssembly.JSTag` viene rimosso all'interno della sandbox per motivi di sicurezza, quindi il codice wasm non può intercettare le eccezioni JavaScript.
-   `allowAsync` - Se impostato su `false`, qualsiasi tentativo di eseguire codice che utilizza `async` genererà un `VMError` (predefinito: `true`).
-   `bufferAllocLimit` - Dimensione massima in byte per una singola richiesta `Buffer.alloc` / `Buffer.allocUnsafe` / `Buffer.allocUnsafeSlow` / `Buffer(N)` / `new Buffer(N)` dall'interno della sandbox. Le richieste che superano questo limite generano un `RangeError` in modo sincrono senza eseguire l'allocazione host. Predefinito: `Infinity` (nessun limite, completamente retrocompatibile). Gli embedder che eseguono codice non attendibile in ambienti con memoria limitata (Docker / Kubernetes / Lambda / serverless) dovrebbero optare per un limite finito (ad es. `32 * 1024 * 1024`) come parte della difesa a strati contro il DoS, allo stesso modo in cui optano per `timeout`. Vedi [Raccomandazioni di hardening](#raccomandazioni-di-hardening) di seguito.

**IMPORTANTE**: Il timeout è efficace solo sul codice sincrono che esegui tramite `run`. Il timeout **NON** funziona su alcun metodo restituito dalla VM. Ci sono alcune situazioni in cui il timeout non funziona - vedi [#244](https://github.com/patriksimek/vm2/pull/244).```js
import { VM } from 'vm2';

const vm = new VM({
	timeout: 1000,
	allowAsync: false,
	sandbox: {},
});

vm.run('process.exit()'); // throws ReferenceError: process is not defined

**SUGGERIMENTO**: Consulta i test per ulteriori esempi di utilizzo.

## NodeVM

A differenza di `VM`, `NodeVM` consente di richiedere moduli nello stesso modo in cui si farebbe nel contesto regolare di Node.

**Opzioni:**

-   `console` - `inherit` per abilitare la console, `redirect` per reindirizzare agli eventi, `off` per disabilitare la console (predefinito: `inherit`).
-   `sandbox` - Oggetto globale della VM.
-   `compiler` - `javascript` (predefinito), `typescript`, `coffeescript` o una funzione di compilazione personalizzata (che riceve il codice e il suo percorso file). La libreria si aspetta che tu abbia il compilatore preinstallato se il valore è impostato su `typescript` o `coffeescript`. **`typescript` richiede `typescript@6` o versioni precedenti** — vedi [Compilatori](#compilers).
-   `eval` - Se impostato su `false`, qualsiasi chiamata a `eval` o ai costruttori di funzioni (`Function`, `GeneratorFunction`, ecc.) genererà un `EvalError` (predefinito: `true`).
-   `wasm` - Se impostato su `false`, qualsiasi tentativo di compilare un modulo WebAssembly genererà un `WebAssembly.CompileError` (predefinito: `true`). Nota: `WebAssembly.JSTag` viene rimosso all'interno della sandbox per motivi di sicurezza, quindi il codice wasm non può intercettare le eccezioni JavaScript.
-   `bufferAllocLimit` - Stessa semantica di `VM` — dimensione massima in byte per una singola richiesta della famiglia `Buffer.alloc` dall'interno della sandbox. Predefinito: `Infinity`. Vedi [Raccomandazioni di hardening](#hardening-recommendations).
-   `sourceExtensions` - Array di estensioni di file da trattare come codice sorgente (predefinito: `['js']`).
-   `require` - `true`, un oggetto o un Resolver per abilitare il metodo `require` (predefinito: `false`).
-   `require.external` - I valori possono essere `true`, un array di moduli esterni consentiti, o un oggetto (predefinito: `false`). Tutti i percorsi che corrispondono a `/node_modules/${qualsiasi_modulo_esterno_consentito}/(?!/node_modules/)` possono essere richiesti.
-   `require.external.modules` - Array di moduli esterni consentiti. Supporta anche i caratteri jolly, quindi specificare `['@scope/*-ver-??]`, ad esempio, consentirà di utilizzare tutti i moduli con un nome della forma `@scope/something-ver-aa`, `@scope/other-ver-11`, ecc. Il carattere jolly `*` non corrisponde ai separatori di percorso.
-   `require.external.transitive` - Booleano che indica se le dipendenze transitive dei moduli esterni sono consentite (predefinito: `false`). **ATTENZIONE**: Quando un modulo viene richiesto transitivamente, qualsiasi modulo può poi richiederlo normalmente, anche se ciò non era possibile prima del suo caricamento.
-   `require.builtin` - Array di moduli integrati consentiti, accetta ["\*"] per tutti (predefinito: nessuno). **ATTENZIONE**: "\*" può essere pericoloso poiché possono essere aggiunti nuovi moduli integrati.
-   `require.root` - Percorso(i) limitato(i) in cui i moduli locali possono essere richiesti (predefinito: ogni percorso).
-   `require.mock` - Raccolta di moduli fittizi (sia esterni che integrati).
-   `require.context` - `host` (predefinito) per richiedere moduli nell'host e inoltrarli nella sandbox. `sandbox` per caricare, compilare e richiedere moduli nella sandbox. `callback(moduleFilename, ext)` per scegliere dinamicamente un contesto per ogni modulo. Il predefinito sarà sandbox se non viene specificato nulla. Ad eccezione di `events`, i moduli integrati vengono sempre richiesti nell'host e inoltrati nella sandbox.
-   `require.import` - Un array di moduli da caricare in NodeVM all'avvio.
-   `require.resolve` - Una funzione di ricerca aggiuntiva nel caso in cui un modulo non venga trovato in uno dei percorsi di ricerca tradizionali di node.
-   `require.customRequire` - Da usare al posto della funzione `require` per caricare moduli dall'host.
-   `require.strict` - `false` per non forzare la modalità strict sui moduli caricati tramite require (predefinito: `true`).
-   `require.fs` - Implementazione personalizzata del file system.
-   `nesting` - **ATTENZIONE**: Consentire questo è un rischio per la sicurezza poiché gli script possono creare una NodeVM che può richiedere qualsiasi modulo host. `true` per abilitare l'annidamento delle VM (predefinito: `false`).
-   `wrapper` - `commonjs` (predefinito) per avvolgere lo script nel wrapper CommonJS, `none` per recuperare il valore restituito dallo script.
-   `argv` - Array da passare a `process.argv`.
-   `env` - Oggetto da passare a `process.env`.
-   `strict` - `true` per caricare i moduli in modalità strict (predefinito: `false`).

**IMPORTANTE**: Il timeout non è efficace per NodeVM, quindi non è immune a `while (true) {}` o simili attacchi.

**RICORDA**: Più moduli consenti, più fragile diventa la tua sandbox.```js
import { NodeVM } from 'vm2';

const vm = new NodeVM({
	console: 'inherit',
	sandbox: {},
	require: {
		external: true,
		builtin: ['fs', 'path'],
		root: './',
		mock: {
			fs: {
				readFileSync: () => 'Nice try!',
			},
		},
	},
});

// Sync

let functionInSandbox = vm.run('module.exports = function(who) { console.log("hello "+ who); }');
functionInSandbox('world');

// Async

let functionWithCallbackInSandbox = vm.run('module.exports = function(who, callback) { callback("hello "+ who); }');
functionWithCallbackInSandbox('world', greeting => {
	console.log(greeting);
});

**SUGGERIMENTO**: Consulta i test per ulteriori esempi di utilizzo.

### Caricamento di moduli tramite percorso relativo

Per caricare moduli tramite percorso relativo, devi passare il percorso completo dello script che stai eseguendo come secondo argomento al metodo `run` di vm se lo script è una stringa. Il nome del file viene quindi visualizzato in qualsiasi stack trace generato dallo script.```js
vm.run('require("foobar")', '/data/myvmscript.js');

### Resolver

Un resolver può essere creato tramite `makeResolverFromLegacyOptions` e utilizzato per più istanze di `NodeVM`, consentendo di condividere il codice dei moduli compilati e potenzialmente accelerando i tempi di caricamento. Il primo esempio di `NodeVM` può essere riscritto utilizzando `makeResolverFromLegacyOptions` come segue.```js
const resolver = makeResolverFromLegacyOptions({
	external: true,
	builtin: ['fs', 'path'],
	root: './',
	mock: {
		fs: {
			readFileSync: () => 'Nice try!',
		},
	},
});
const vm = new NodeVM({
	console: 'inherit',
	sandbox: {},
	require: resolver,
});

Funziona sia per `VM` che per `NodeVM`.```js
import { NodeVM, VMScript } from 'vm2';

const vm = new NodeVM();
const script = new VMScript('module.exports = Math.random()');
console.log(vm.run(script));
console.log(vm.run(script));

Either pin `typescript@6`, or supply your own transpiler — any function returning JavaScript works, so TypeScript 7's `tsc`, esbuild, swc, or a type-stripper are all valid:```js
import { VM, VMScript } from 'vm2';
import { transformSync } from 'esbuild';

const script = new VMScript('const x: number = 1; x', {
	compiler: (code, filename) => transformSync(code, { loader: 'ts', format: 'cjs' }).code,
});

new VM().run(script);

## Debug di un codice in sandbox

Puoi eseguire il debug o ispezionare il codice in esecuzione nella sandbox come se fosse eseguito in un processo normale.

-   Puoi usare i breakpoint (che richiedono di specificare un nome di file di script)
-   Puoi usare la parola chiave `debugger`.
-   Puoi usare step-in per entrare nel codice in esecuzione nella sandbox.

### Esempio

/tmp/main.js:```js
import { VM, VMScript } from 'vm2';
import { readFileSync } from 'node:fs';

const file = `${__dirname}/sandbox.js`;

// By providing a file name as second argument you enable breakpoints
const script = new VMScript(readFileSync(file), file);

new VM().run(script);

## Oggetti di sola lettura (sperimentale)

Per impedire agli script in sandbox di aggiungere, modificare o eliminare proprietà dagli oggetti proxy, puoi usare i metodi `freeze` per rendere l'oggetto di sola lettura. Questo è efficace solo all'interno della VM. Gli oggetti congelati vengono influenzati in profondità. I tipi primitivi non possono essere congelati.

**Esempio senza usare `freeze`:**```js
const util = {
	add: (a, b) => a + b,
};

const vm = new VM({
	sandbox: { util },
});

vm.run('util.add = (a, b) => a - b');
console.log(util.add(1, 1)); // returns 0

**IMPORTANTE:** Non è possibile congelare oggetti che sono già stati inoltrati tramite proxy alla VM.

## Oggetti protetti (sperimentale)

A differenza di `freeze`, questo metodo consente agli script in sandbox di aggiungere, modificare o eliminare proprietà sugli oggetti, con un'eccezione: non è possibile associare funzioni. Gli script in sandbox non sono quindi in grado di modificare metodi come `toJSON`, `toString` o `inspect`.

**IMPORTANTE:** Non è possibile proteggere oggetti che sono già stati inoltrati tramite proxy alla VM.

## Relazioni tra sandbox```js
const assert = require('assert');
const { VM } = require('vm2');

const sandbox = {
	object: new Object(),
	func: new Function(),
	buffer: new Buffer([0x01, 0x05]),
};

const vm = new VM({ sandbox });

assert.ok(vm.run(`object`) === sandbox.object);
assert.ok(vm.run(`object instanceof Object`));
assert.ok(vm.run(`object`) instanceof Object);
assert.ok(vm.run(`object.__proto__ === Object.prototype`));
assert.ok(vm.run(`object`).__proto__ === Object.prototype);

assert.ok(vm.run(`func`) === sandbox.func);
assert.ok(vm.run(`func instanceof Function`));
assert.ok(vm.run(`func`) instanceof Function);
assert.ok(vm.run(`func.__proto__ === Function.prototype`));
assert.ok(vm.run(`func`).__proto__ === Function.prototype);

assert.ok(vm.run(`new func() instanceof func`));
assert.ok(vm.run(`new func()`) instanceof sandbox.func);
assert.ok(vm.run(`new func().__proto__ === func.prototype`));
assert.ok(vm.run(`new func()`).__proto__ === sandbox.func.prototype);

assert.ok(vm.run(`buffer`) === sandbox.buffer);
assert.ok(vm.run(`buffer instanceof Buffer`));
assert.ok(vm.run(`buffer`) instanceof Buffer);
assert.ok(vm.run(`buffer.__proto__ === Buffer.prototype`));
assert.ok(vm.run(`buffer`).__proto__ === Buffer.prototype);
assert.ok(vm.run(`buffer.slice(0, 1) instanceof Buffer`));
assert.ok(vm.run(`buffer.slice(0, 1)`) instanceof Buffer);

## Raccomandazioni di hardening

vm2 previene le evasioni della sandbox (codice non fidato che ottiene accesso al realm dell'host). Non previene, **da solo**, ogni forma di esaurimento delle risorse o denial-of-service. Gli integratori che eseguono codice non fidato dovrebbero aggiungere le seguenti difese a strati attorno alla sandbox.

### 1. Limitare l'allocazione di memoria con `bufferAllocLimit`

Una singola chiamata `Buffer.alloc(N)` con `N` controllato dall'attaccante viene eseguita come un'unica allocazione C++ sincrona dell'host che il `timeout` di V8 non può interrompere. In ambienti con memoria limitata, un payload della sandbox di ~100 byte può far aumentare l'RSS dell'host di oltre 100 MB e mandare in crash il processo host tramite OOM. Imposta `bufferAllocLimit` (ad es. `32 * 1024 * 1024`) per limitare le singole allocazioni:```js
const vm = new VM({
	timeout: 1000,
	bufferAllocLimit: 32 * 1024 * 1024,
	allowAsync: false,
});

Se la tua applicazione non ha altre fonti di rejection non gestite, un "swallow" generico + log è accettabile:```js
process.on('unhandledRejection', reason => {
	yourLogger.warn('swallowed sandbox rejection', reason);
});

Se imposti `nesting: true`, hai di fatto concesso alla sandbox lo stesso livello di fiducia che hai tu. **Non abilitare `nesting: true` per codice non attendibile.** Usalo solo quando ti fidi del codice in sandbox ma vuoi una semantica di esecuzione in stile VM (global fresco, timeout controllati) per motivi non legati alla sicurezza.

`nesting: true` **richiede un oggetto `require` esplicito** (es. `require: { builtin: [] }` o `require: {}`). Qualsiasi altra forma — `require: false`, `require: undefined`, `require: null`, o l'omissione di `require` — genera un `VMError` in fase di costruzione (GHSA-m4wx-m65x-ghrr, che sostituisce GHSA-8hg8-63c5-gwmx). Tutte queste forme producono un resolver solo-NESTING_OVERRIDE: la sandbox può fare `require('vm2')` ma nient'altro, il che è una pura primitiva di fuga senza alcun uso legittimo. Per negare tutti i require, rimuovi `nesting: true`. Per consentire VM annidate, fornisci una configurazione `require` esplicita così che il compromesso sia visibile nel punto di chiamata.

## Problemi noti

-   Non è possibile definire una classe che estende una classe proxata. Questo include l'uso di una classe proxata in `Object.create`.
-   L'eval diretta non funziona.
-   Il logging degli array della sandbox ripeterà la parte dell'array nelle proprietà.
-   Le trasformazioni del codice sorgente possono produrre una stringa sorgente diversa per una funzione.
-   Ci sono modi per far crashare il processo node dall'interno della sandbox. Vedi [Raccomandazioni per l'hardening](#hardening-recommendations).
-   Il compilatore `typescript` integrato non funziona con TypeScript 7 o versioni successive, che hanno rimosso l'API `transpileModule()` usata da vm2. Usa `typescript@6` o passa il tuo transpiler — vedi [Compilers](#compilers).

[npm-image]: https://img.shields.io/npm/v/vm2.svg
[npm-url]: https://www.npmjs.com/package/vm2
[license-image]: https://img.shields.io/npm/l/vm2.svg
[license-url]: https://raw.githubusercontent.com/patriksimek/vm2/resurrection/LICENSE.md
[downloads-image]: https://img.shields.io/npm/dm/vm2.svg
[downloads-url]: https://www.npmjs.com/package/vm2
[snyk-image]: https://snyk.io/test/github/patriksimek/vm2/badge.svg
[snyk-url]: https://snyk.io/test/github/patriksimek/vm2