Se provi ad installare l'ultima versione di node usando il gestore di pacchetti apt finirai con l'avere la versione 10.19.0. Questa è l'ultima versione presente nell'app store ubuntu ma non è l'ultima versione rilasciata da NodeJS.

N.d.T.
Le versioni menzionate fanno riferimento al momento della pubblicazione dell'articolo e non sono aggiornate.

Questo succede perché le nuove versioni software rilasciate richiedono mesi prima che il team di Ubuntu le testi e le rilasci nel proprio store ufficiale. Per ottenere l'ultima versione di qualsiasi software dovresti usare pacchetti privati, pubblicati direttamente dagli sviluppatori.

In questo tutorial, quello che vogliamo è ottenere Node v12.18.1 (LTS - con supporto a lungo termine) o v14.4. Per ottenere le ultime versioni possiamo usare nodesource o nvm (node version manager). Ti farò vedere entrambi i modi.

Tutti i comandi saranno eseguiti utilizzando l'interfaccia a riga di comando (CLI) di Ubuntu.

Usare NVM - il mio metodo preferito

Il motivo per cui preferisco nvm è perché permette di muoversi tra diverse versione di node in base al progetto. Capiterà di collaborare a diversi progetti con diverse versioni di node e dunque dover cambiare versione in base a quella richiesta. Per questo nvm è lo strumento migliore.

Installare NVM

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.35.3/install.sh | bash

Per controllare l'effettiva installazione di nvm scrivi nel terminale nvm --version. Se la risposta è qualcosa tipo 0.35.3 allora sai che è stato installato correttamente.

Riavvia il tuo terminale per rendere effettivi i cambiamenti.

Installare NodeJS

Installiamo NodeJS versione 14.4.

Semplicemente digita il comando nvm install 14.4.0 e fai invio.

Puoi decidere quale versione installare usando lo stesso comando ma con la versione che desideri. Ad esempio: nvm install 12.18.1.

Eseguendo il comando verrà installata la versione di NodeJS scelta e automaticamente l'ultima versione di npm che potrebbe essere v6.14.5.

Se desideri spostarti su una versione di node specifica puoi semplicemente usare il comando nvm use <numero-versione>, ad esempio nvm use v12.18.1.

Per visualizzare la lista delle diverse versioni di node installate con nvm puoi usare il comando nvm ls.

Installare Nodesource

Esegui questo comando per dire a Ubuntu che vuoi installare il pacchetto di NodeJS da nodesource.

curl -sL https://deb.nodesource.com/setup_14.x | sudo -E bash -

N.B., la versione v14.4.0 è l'ultima versione di Node ma non ha il supporto a lungo termine (LTS). Per installare la versione di Node con LTS cambia il numero della versione da 14 a 12 nel comando.

È probabile ti venga chiesto di inserire password per l'utente root. Scrivila e premi invio.

Installare NodeJS

Una volta sistemato Nodesource possiamo installare NodeJS v14.4. Esegui sudo apt-get install -y nodejs.

Una volta fatto, possiamo controllare se effettivamente abbiamo l'ultima versione installata. Possiamo farlo usando il comando nodejs -v che dovrebbe restituire v14.4.0.

Dovresti avere installato npm in automatico. Per controllare che versione hai puoi usare questo comando: npm version. Se non ottieni un oggetto che include l'ultima versione di npm, o qualcosa di simile a 6.14.5 ({ npm: '6.14.5' }), allora puoi aggiornare manualmente npm con il seguente comando:

npm install -g npm@latest.

Se dovessero esserci problemi con npm che non può essere aggiornato perché risulta non installato, puoi prima usare il comando sudo apt-get install -y npm, e poi usare il comando precedente per aggiornare.

Per avviare alcuni pacchetti npm potresti avere bisogno di questo comando:

sudo apt install build-essential.

E questo è tutto.

Hai l'ultima versione di NodeJS e NPM sulla tua macchina Ubuntu.

Buona programmazione:)

Node è un ambiente di runtime che consente agli sviluppatori di eseguire il codice JavaScript al di fuori del browser, nel lato server.

NPM, invece, è un gestore di pacchetti per pubblicare pacchetti JavaScript (anche detti moduli Node) nel registro npm. Puoi anche usarlo per installare pacchetti per le tue applicazioni.

Per installare Node, devi andare sul sito di Nodejs e scaricare l'installer. Dopo il download, esegui l'installer e segui i passaggi, accetta i termini di utilizzo e aspetta che l'installazione sia terminata.

Quando installi Node, ottieni anche la CLI npm che puoi usare per gestire i pacchetti nelle tua applicazioni.

Tuttavia, Node e NPM possono essere aggiornati separatamente alle loro ultime versioni, e nel resto di questo articolo ti mostrerò come.

Come aggiornare Node

1. Usa NPM per aggiornare la versione di Node

Per aggiornare Node con NPM, installa il pacchetto n, che servirà per gestire in modo interattivo le versioni di node sul tuo dispositivo.

Ecco i passaggi:

Pulisci la cache di NPM

Quando installi le dipendenze, alcuni moduli vengono memorizzati nella cache per migliorare la velocità dell'installazione per i download successivi. Quindi, prima di tutto, pulisci la cache di NPM.

Installa n

npm install -g n

Ti occorrerà installare questo pacchetto globalmente dato che gestisce alla radice le versioni di Node.

Installa una nuova versione di Node

n lts
n latest

I due comandi qui sopra installano l'ultima versione di Node con supporto a lungo termine.

Rimuovi le versioni precedentemente installate

n prune

Questo comando rimuove le versioni precedentemente installate salvate nella cache mantenendo soltanto l'ultima versione.

2. Usa NVM per aggiornare la versione di Node

NVM sta per Node Version Manager (gestore di versione di Node) e, come suggerisce il nome, aiuta la gestione delle versioni di Node. Con NVM puoi installare delle versioni di Node e specificare la versione da utilizzare in un progetto.

NVM rende semplice testare dei progetti con diverse versioni di Node.

Per aggiornare la versione di Node con NVM, devi prima installare NVM.

Ecco la guida di installlazione.

Una volta terminata l'installazione, puoi installare i pacchetti con:

nvm install [versione]

Puoi installare l'ultima versione con:

nvm install node

E disinstallare le altre versioni con:

nvm uninstall [versione]

Con molte versioni installate, potresti aver bisogno di specificare la versione da utilizzare in un determinato momento. Un modo per farlo è impostare un alias predefinito, così:

nvm alias default [versione]

In questo modo, verrà eseguita la versione di Node specificata.

3. Scarica Node dal sito

Puoi anche ottenere l'ultima versione direttamente dal sito di Node.js, dove puoi trovare l'ultima versione e le versioni con supporto a lungo termine per il tuo dispositivo.

Scaricando l'ultima versione ottieni anche l'ultima versione di NPM.

Come aggiornare NPM

Proprio come usi NPM per aggiornare pacchetti, puoi usarlo anche per aggiornare sé stesso. Ecco il comando per farlo:

npm install -g npm@latest

Questo comando installerà l'ultima versione di NPM globalmente.

Su Mac, potresti dover usare il comando sudo prima di NPM, dato che installa NPM nella radice del tuo dispositivo e per farlo ti occorrono privilegi.

Conclusione

In questo articolo, abbiamo visto come aggiornare Node e NPM all'ultima versione.

Ricapitolando, quando installi Node, ottieni automaticamente anche NPM. E ottieni NPM anche se aggiorni Node tramite il download dal sito web.

Infine abbiamo anche visto come aggiornare Node e NPM globalmente sul tuo dispositivo.

Aggiornamento: questo articolo fa ora parte del mio libro "Node.js Beyond The Basics".

Leggi la versione aggiornata di questo contenuto e altro su Node su jscomplete.com/node-beyond-basics .

Node utilizza due moduli principali per la gestione delle dipendenze dei moduli:

• Il modulorequire, che è disponibile nell'ambito globale, quindi non è necessario richiede require('require').
• Il modulo module, che è anche disponibile nell'ambito globale, e non è necessario richiedere require('module').

Puoi pensare al modulo require come al comando e al modulo module come al raccoglitore di tutti i moduli richiesti.

Richiedere un modulo in Node non è un concetto così complicato.

const config = require('/path/to/file');

L'oggetto principale esportato dal modulo require è una funzione (come nell'esempio precedente). Quando richiama quella funzione require() con un percorso di file locale come unico argomento della funzione, Node esegue la seguente sequenza di passaggi:

• Risoluzione : per trovare il percorso assoluto del file.
• Caricamento : per determinare il tipo di contenuto del file.
• Wrapping : per assegnare al file il suo ambito privato. Questo è ciò che rende gli oggetti require e module locali in ogni file di cui abbiamo bisogno.
• Valutazione : questo è ciò che la VM alla fine fa con il codice caricato.
• Memorizzazione nella cache : in modo che quando richiediamo nuovamente questo file, non ripercorriamo tutti i passaggi un'altra volta.

In questo articolo, cercherò di spiegare con esempi, queste diverse fasi e come influiscono sul modo in cui scriviamo i moduli in Node.

Fammi prima creare una directory per ospitare tutti gli esempi usando il mio terminale:

mkdir ~/learn-node && cd ~/learn-node

Tutti i comandi nel resto di questo articolo verranno eseguiti dall'interno di ~/learn-node.

Risoluzione di un percorso locale

Lascia che ti presenti l'oggetto module. Puoi verificarlo in una semplice sessione REPL:

~/learn-node $ node
> module
Module {
  id: '<repl>',
  exports: {},
  parent: undefined,
  filename: null,
  loaded: false,
  children: [],
  paths: [ ... ] }

Ogni oggetto modulo ottiene una proprietà id per identificarlo. Questo id è solitamente il percorso completo del file, ma in una sessione REPL è semplicemente<repl>.

I moduli del nodo hanno una relazione uno-a-uno con i file sul file system. Richiediamo un modulo caricando il contenuto di un file in memoria.

Tuttavia, poiché Node permette molti modi di richiedere un file (ad esempio, con un percorso relativo o un percorso preconfigurato), prima di poter caricare il contenuto di un file nella memoria, dobbiamo trovare la posizione assoluta di quel file.

Quando richiediamo un modulo 'find-me', senza specificare un percorso:

require('find-me');

Il nodo cercherà find-me.js in tutti i percorsi specificati da module.paths— in ordine.

~/learn-node $ node
> module.paths
[ '/Users/samer/learn-node/repl/node_modules',
  '/Users/samer/learn-node/node_modules',
  '/Users/samer/node_modules',
  '/Users/node_modules',
  '/node_modules',
  '/Users/samer/.node_modules',
  '/Users/samer/.node_libraries',
  '/usr/local/Cellar/node/7.7.1/lib/node' ]

L'elenco dei percorsi è fondamentalmente un elenco di directory di node_modules, dalla directory corrente alla directory principale. Include anche alcune directory legacy il cui utilizzo non è raccomandato.

Se Node non riesce a trovare find-me.js in nessuno di questi percorsi, genererà un "cannot find module error".

~/learn-node $ node
> require('find-me')
Error: Cannot find module 'find-me'
    at Function.Module._resolveFilename (module.js:470:15)
    at Function.Module._load (module.js:418:25)
    at Module.require (module.js:498:17)
    at require (internal/module.js:20:19)
    at repl:1:1
    at ContextifyScript.Script.runInThisContext (vm.js:23:33)
    at REPLServer.defaultEval (repl.js:336:29)
    at bound (domain.js:280:14)
    at REPLServer.runBound [as eval] (domain.js:293:12)
    at REPLServer.onLine (repl.js:533:10)

Se ora crei una directory locale node_modules e inserisci un file find-me.js lì, la riga require('find-me') la troverà.

~/learn-node $ mkdir node_modules 

~/learn-node $ echo "console.log('Non mi sono perso');" > node_modules/find-me.js

~/learn-node $ node
> require('find-me');
Non mi sono perso
{}
>

Se esistesse un altro file find-me.js in uno qualsiasi degli altri percorsi, ad esempio, se avessimo una directory node_modules nella directory home e avessimo un diverso file find-me.js in quella cartella:

$ mkdir ~/node_modules
$ echo "console.log('Io sono la radice di tutti i problemi');" > ~/node_modules/find-me.js

Quando eseguiamo require('find-me') nella directory learn-node, che ha il suo node_modules/find-me.js, il file find-me.js nella directory home non verrà caricato affatto:

~/learn-node $ node
> require('find-me')
Non mi sono perso
{}
>

Se rimuoviamo la directory locale node_modules in ~/learn-node e proviamo a richiede find-me ancora una volta, verrà utilizzato il file nella directory home node_modules :

~/learn-node $ rm -r node_modules/
~/learn-node $ node
> require('find-me')
Io sono la radice di tutti i problemi
{}
>

Richiedere una cartella

I moduli possono non essere file. Possiamo anche creare una cartella find-me sotto node_modules e inserire lì un file index.js. La stessa riga require('find-me') utilizzerà il file index.js di quella cartella:

~/learn-node $ mkdir -p node_modules/find-me

~/learn-node $ echo "console.log('Ritrovato.');" > node_modules/find-me/index.js

~/learn-node $ node
> require('find-me');
Ritrovato.
{}
>

Nota come ha ancora ignorato il percorso della home directory node_modules poiché ne abbiamo una locale.

Un file index.js verrà utilizzato per impostazione predefinita quando richiediamo una cartella, ma possiamo indicare con quale file iniziare nella cartella utilizzando la proprietà main in package.json. Ad esempio, per fare in modo che la riga require('find-me') si risolva in un file diverso nella cartella find-me, tutto ciò che dobbiamo fare è aggiungere lì un file package.json e specificare quale file deve essere usato per risolvere questa cartella:

~/learn-node $ echo "console.log('I rule');" > node_modules/find-me/start.js

~/learn-node $ echo '{ "name": "find-me-folder", "main": "start.js" }' > node_modules/find-me/package.json

~/learn-node $ node
> require('find-me');
I rule
{}
>

require.resolve

Se vuoi solo risolvere il modulo e non eseguirlo, puoi usare la funzione require.resolve . Questa si comporta esattamente come la funzione principale require , ma non carica il file. Verrà comunque generato un errore se il file non esiste e restituirà il percorso completo del file una volta trovato.

> require.resolve('find-me');
'/Users/samer/learn-node/node_modules/find-me/start.js'
> require.resolve('not-there');
Error: Cannot find module 'not-there'
    at Function.Module._resolveFilename (module.js:470:15)
    at Function.resolve (internal/module.js:27:19)
    at repl:1:9
    at ContextifyScript.Script.runInThisContext (vm.js:23:33)
    at REPLServer.defaultEval (repl.js:336:29)
    at bound (domain.js:280:14)
    at REPLServer.runBound [as eval] (domain.js:293:12)
    at REPLServer.onLine (repl.js:533:10)
    at emitOne (events.js:101:20)
    at REPLServer.emit (events.js:191:7)
>

Questo può essere utilizzato, ad esempio, per verificare se un pacchetto opzionale è installato o meno e utilizzarlo solo quando è disponibile.

Percorsi relativi e assoluti

Oltre a risolvere i moduli dall'interno delle directory node_modules, possiamo anche posizionare il modulo dove vogliamo e richiederlo con percorsi relativi ( ./e ../) o con percorsi assoluti che iniziano con /.

Se, ad esempio, il file find-me.js era in una cartella lib anziché in una cartella node_modules, possiamo richiederlo con:

require('./lib/find-me');

Relazione genitore-figlio tra file

Crea un file lib/util.js e aggiungi una riga console.log per identificarlo. Inoltre, stampa con console.log l'oggetto stesso module:

~/learn-node $ mkdir lib
~/learn-node $ echo "console.log('In util', module);" > lib/util.js

Fai lo stesso per un file index.js, che è ciò che eseguiremo con il comando node. Fai in modo che questo file index.js richieda lib/util.js:

~/learn-node $ echo "console.log('In index', module); require('./lib/util');" > index.js

Ora esegui il file index.js con node:

~/learn-node $ node index.js
In index Module {
  id: '.',
  exports: {},
  parent: null,
  filename: '/Users/samer/learn-node/index.js',
  loaded: false,
  children: [],
  paths: [ ... ] }
In util Module {
  id: '/Users/samer/learn-node/lib/util.js',
  exports: {},
  parent:
   Module {
     id: '.',
     exports: {},
     parent: null,
     filename: '/Users/samer/learn-node/index.js',
     loaded: false,
     children: [ [Circular] ],
     paths: [...] },
  filename: '/Users/samer/learn-node/lib/util.js',
  loaded: false,
  children: [],
  paths: [...] }

Nota come il modulo principale index (id: '.') sia ora elencato come genitore per il modulo lib/util. Tuttavia, il modulo lib/util non è stato elencato come figlio del modulo index. Invece, abbiamo lì il valore [Circular] perché questo è un riferimento circolare. Se Node stampa l'oggetto modulo lib/util, entrerà in un ciclo infinito. Ecco perché sostituisce semplicemente il riferimento lib/util con [Circular].

Cosa ancora più importante ora, cosa succede se il modulo lib/util richiede il modulo principale index? È qui che entriamo in quella che è nota come la dipendenza modulare circolare, consentita in Node.

Per capirlo meglio, comprendiamo prima alcuni altri concetti sull'oggetto module.

exports, module.exports e caricamento sincrono dei moduli

In ogni modulo, exports è un oggetto speciale. Se hai notato sopra, ogni volta che abbiamo stampato un oggetto module, aveva una proprietà exports che è stata finora un oggetto vuoto. Possiamo aggiungere qualsiasi attributo a questo speciale oggetto di esportazione . Ad esempio, esportiamo un attributo id per index.js e lib/util.js:

// Aggiungi la riga seguente in cima a lib/util.js
exports.id = 'lib/util';

// Aggiungi la riga seguente in cima a index.js
exports.id = 'index';

Quando ora eseguiamo index.js, vedremo questi attributi come gestiti sull'oggetto module di ogni file:

~/learn-node $ node index.js
In index Module {
  id: '.',
  exports: { id: 'index' },
  loaded: false,
  ... }
In util Module {
  id: '/Users/samer/learn-node/lib/util.js',
  exports: { id: 'lib/util' },
  parent:
   Module {
     id: '.',
     exports: { id: 'index' },
     loaded: false,
     ... },
  loaded: false,
  ... }

Ho rimosso alcuni attributi nell'output sopra per mantenerlo breve, ma nota come l'oggetto exports ora ha gli attributi che abbiamo definito in ciascun modulo. Puoi inserire tutti gli attributi che vuoi su quell'oggetto exports e puoi effettivamente cambiare l'intero oggetto in qualcos'altro. Ad esempio, per modificare l'oggetto exports in modo che sia una funzione anziché un oggetto, procediamo come segue:

// Aggiungi la riga seguente index.js prima di console.log

module.exports = function() {};

Ora quando esegui index.js, vedrai come l'oggetto exports sia una funzione:

~/learn-node $ node index.js
In index Module {
  id: '.',
  exports: [Function],
  loaded: false,
  ... }

Nota come non abbiamo fatto exports = function() {}per trasformare l'oggetto exports in una funzione. In realtà non possiamo farlo perché la variabile exports all'interno di ogni modulo è solo un riferimento a module.exports che gestisce le proprietà esportate. Quando riassegnamo la variabile exports, quel riferimento viene perso e introdurremmo una nuova variabile invece di cambiare l'oggetto module.exports.

L'oggetto module.exports in ogni modulo è ciò che la funzione require restituisce quando richiediamo quel modulo. Ad esempio, cambia la riga require('./lib/util') in index.js:

const UTIL = require('./lib/util');

console.log('UTIL:', UTIL);

Questo catturerà le proprietà esportate in lib/util nella costante UTIL. Ora quando eseguiamo index.js, l'ultima riga produrrà:

UTIL: { id: 'lib/util' }

Parliamo anche dell'attributo loaded di ogni modulo. Finora, ogni volta che abbiamo stampato un oggetto module, abbiamo visto un attributo loaded in quell'oggetto con un valore false.

Il modulo module utilizza l'attributo loaded per tenere traccia di quali moduli sono stati caricati (valore true) e quali moduli sono ancora in fase di caricamento (valore false). Possiamo, ad esempio, vedere il modulo index.js completamente caricato se stampiamo il suo oggetto module nel ciclo successivo nel ciclo di eventi utilizzando una chiamata setImmediate:

// In index.js
setImmediate(() => {
  console.log('Oggetto del modulo index.js è ora caricato!', module)
});

L'output sarebbe:

Oggetto del modulo index.js è ora caricato! Module {
  id: '.',
  exports: [Function],
  parent: null,
  filename: '/Users/samer/learn-node/index.js',
  loaded: true,
  children:
   [ Module {
       id: '/Users/samer/learn-node/lib/util.js',
       exports: [Object],
       parent: [Circular],
       filename: '/Users/samer/learn-node/lib/util.js',
       loaded: true,
       children: [],
       paths: [Object] } ],
  paths:
   [ '/Users/samer/learn-node/node_modules',
     '/Users/samer/node_modules',
     '/Users/node_modules',
     '/node_modules' ] }

Nota come in questo output ritardato di console.log sia lib/util.js che index.js sono completamente caricati.

L'oggetto exports diventa completo quando Node termina il caricamento del modulo (e lo etichetta così). L'intero processo di richiesta/caricamento di un modulo è sincrono. Ecco perché siamo stati in grado di vedere i moduli completamente caricati dopo un ciclo nel ciclo degli eventi.

Ciò significa anche che non possiamo modificare l'oggetto exports in modo asincrono. Non possiamo, ad esempio, fare quanto segue in nessun modulo:

fs.readFile('/etc/passwd', (err, data) => {
  if (err) throw err;
  
  exports.data = data; // Non funzionerà.
});

Dipendenza del modulo circolare

Proviamo ora a rispondere all'importante domanda sulla dipendenza circolare in Node: cosa succede quando il modulo 1 richiede il modulo 2 e il modulo 2 richiede il modulo 1?

Per scoprirlo, creiamo i seguenti due file in lib/, module1.js e module2.js e facciamo in modo che si richiedano a vicenda:

// lib/module1.js

exports.a = 1;

require('./module2');

exports.b = 2;
exports.c = 3;

// lib/module2.js

const Module1 = require('./module1');
console.log('Module1 è parzialmente caricato qui', Module1);

Quando eseguiamo module1.js si vedrà quanto segue:

~/learn-node $ node lib/module1.js
Module1 è parzialmente caricato qui { a: 1 }

Abbiamo richiesto module2 prima che module1 fosse completamente caricato e poiché module2 ha richiesto module1 prima del suo completo caricamento, ciò che otteniamo dall'oggetto exports a quel punto sono tutte le proprietà esportate prima della dipendenza circolare. Solo la proprietà a è stata riportata perché sia b che c sono stati esportati dopo aver richiesto module2 e stampato module1.

Node rende ciò davvero semplice. Durante il caricamento di un modulo, costruisce l'oggetto exports. Puoi richiedere il modulo prima che il caricamento sia terminato e otterrai solo un oggetto exports parziale con tutto ciò che è stato definito sino a quel momento.

Componenti aggiuntivi JSON e C/C++

Possiamo richiedere in modo nativo file JSON e file aggiuntivi C++ con la funzione require. Non è nemmeno necessario specificare un'estensione di file per farlo.

Se non è stata specificata un'estensione di file, la prima cosa che Node tenterà di risolvere è un file .js. Se non riesce a trovare un file .js, proverà un file .json e lo analizzerà se trovato come file di testo JSON. Successivamente, proverà a trovare un file binario .node. Tuttavia, per rimuovere l'ambiguità, sarebbe meglio specificare un'estensione di file quando richiedi qualcosa di diverso dai file .js.

La richiesta di file JSON è utile se, ad esempio, tutto ciò che devi gestire in quel file sono alcuni valori di configurazione statici o alcuni valori che leggi periodicamente da un'origine esterna. Ad esempio, se avessimo il seguente file config.json:

{
  "host": "localhost",
  "port": 8080
}

Possiamo richiederlo direttamente in questo modo:

const { host, port } = require('./config');

console.log(`Il server verrà eseguito a http://${host}:${port}`);

L'esecuzione del codice sopra avrà questo output:

Il server verrà eseguito a http://localhost:8080

Se Node non riesce a trovare un file .js o un file .json, cercherà un file .node e interpreterà il file come un modulo aggiuntivo compilato.

Il sito della documentazione di Node ha un file aggiuntivo di esempio scritto in C++. È un modulo semplice che espone una funzione hello() che stampa "hello world".

È possibile utilizzare il pacchetto node-gyp per compilare e creare il file .cc in un file .node. Devi solo configurare un file binding.gyp per dire a node-gyp cosa fare.

Una volta che hai il file addon.node (o qualunque nome tu specifichi in binding.gyp), puoi richiederlo in modo nativo proprio come qualsiasi altro modulo:

const addon = require('./addon');

console.log(addon.hello());

Possiamo effettivamente vedere il supporto delle tre estensioni guardando require.extensions.

Osservando le funzioni per ciascuna estensione, puoi vedere chiaramente cosa farà Node con ciascuna. Esso utilizza module._compile per i file .js, JSON.parse per i file .json e process.dlopen per i file .node.

Tutto il codice che scrivi in ​​Node sarà racchiuso in funzioni

Il wrapping dei moduli da parte di Node è spesso frainteso. Per capirlo, lascia che ti ricordi la relazione exports/ module.exports.

Possiamo usare l'oggetto exports per esportare le proprietà, ma non possiamo sostituire l'oggetto exports direttamente perché è solo un riferimento a module.exports

exports.id = 42; // Questo è ok.

exports = { id: 42 }; // Questo non va bene.

module.exports = { id: 42 }; // Questo è ok.

In che modo esattamente questo oggetto exports, che sembra essere globale per ogni modulo, viene definito come riferimento sull'oggetto module ?

Consentitemi di porre un'altra domanda prima di spiegare il processo di wrapping di Node.

In un browser, quando dichiariamo una variabile in uno script come questo:

var answer = 42;

Quella variabile answer sarà globalmente disponibile in tutti gli script dopo lo script che l'ha definita.

Questo non è il caso di Node. Quando definiamo una variabile in un modulo, gli altri moduli del programma non avranno accesso a quella variabile. Quindi, come mai le variabili in Node hanno magicamente un ambito globale?

La risposta è semplice. Prima di compilare un modulo, Node racchiude il codice del modulo stesso in una funzione, che possiamo ispezionare usando la proprietà wrapper del modulo module.

~ $ node
> require('module').wrapper
[ '(function (exports, require, module, __filename, __dirname) { ',
  '\n});' ]
>

Node non esegue direttamente il codice che scrivi in ​​un file. Esegue questa funzione wrapper che avrà il tuo codice nel suo corpo. Questo è ciò che mantiene le variabili di primo livello, che sono definite in qualsiasi modulo con ambito a questo modulo.

Questa funzione wrapper ha 5 argomenti: exports, require, module, __filename e __dirname. Questo è ciò che li fa sembrare globali quando in realtà sono specifici per ciascun modulo.

Tutti questi argomenti ottengono i loro valori quando Node esegue la funzione wrapper. exports è definito come un riferimento a module.exports prima di quello. require e module sono entrambi specifici della funzione da eseguire, e le variabili __filename/ __dirname conterranno il nome assoluto del file del modulo wrapped e il percorso della directory.

Puoi vedere questo wrapping in azione se esegui uno script con un problema sulla prima riga:

~/learn-node $ echo "euaohseu" > bad.js

~/learn-node $ node bad.js
~/bad.js:1
(function (exports, require, module, __filename, __dirname) { euaohseu
                                                              ^
ReferenceError: euaohseu is not defined

Nota come la prima riga dello script riportato sopra, fosse la funzione wrapper, non il riferimento errato.

Inoltre, poiché ogni modulo viene racchiuso in una funzione, possiamo effettivamente accedere agli argomenti di quella funzione con la parola chiave arguments:

~/learn-node $ echo "console.log(arguments)" > index.js

~/learn-node $ node index.js
{ '0': {},
  '1':
   { [Function: require]
     resolve: [Function: resolve],
     main:
      Module {
        id: '.',
        exports: {},
        parent: null,
        filename: '/Users/samer/index.js',
        loaded: false,
        children: [],
        paths: [Object] },
     extensions: { ... },
     cache: { '/Users/samer/index.js': [Object] } },
  '2':
   Module {
     id: '.',
     exports: {},
     parent: null,
     filename: '/Users/samer/index.js',
     loaded: false,
     children: [],
     paths: [ ... ] },
  '3': '/Users/samer/index.js',
  '4': '/Users/samer' }

Il primo argomento è l'oggetto exports, che inizialmente è vuoto. Quindi abbiamo gli oggetti require/ module, entrambi istanze associate al file index.js che stiamo eseguendo. Non sono variabili globali. Gli ultimi 2 argomenti sono il percorso del file e il percorso della sua directory.

Il valore restituito dalla funzione di wrapping è module.exports. All'interno della funzione wrapped, possiamo utilizzare l'oggetto exports per modificare le proprietà di module.exports, ma non possiamo riassegnare exports perché è solo un riferimento.

Quello che succede è più o meno equivalente a:

function (require, module, __filename, __dirname) {
  let exports = module.exports;
  
  // Il tuo codice...
  
  return module.exports;
}

Se cambiassimo l'intero oggetto exports, non sarebbe più un riferimento a module.exports. Questo è il modo in cui la referenziazione degli oggetti di JavaScript funziona ovunque, non solo in questo contesto.

L'oggetto require

Non c'è niente di speciale in require. È un oggetto che agisce principalmente come una funzione che prende il nome di modulo o un percorso e restituisce l'oggetto module.exports. Possiamo semplicemente sovrascrivere l'oggetto require con la nostra logica, se vogliamo.

Ad esempio, a solo scopo di test, vogliamo che ogni chiamata require venga ingannata per impostazione predefinita e restituisca semplicemente un oggetto falso invece dell'oggetto di esportazione del modulo richiesto. Questa semplice riassegnazione di require farà il trucco:

require = function() {

  return { mocked: true };
  
}

Dopo aver eseguito la suddetta riassegnazione di require, ogni chiamata require('something') nello script restituirà semplicemente l'oggetto che abbiamo definito.

L'oggetto require ha anche proprietà proprie. Abbiamo visto la proprietà resolve, che è una funzione che esegue solo la fase di risoluzione del processo require. Sopra abbiamo visto anche require.extensions.

C'è anche require.main che può essere utile per determinare se lo script è richiesto o eseguito direttamente.

Supponiamo, ad esempio, di avere questa semplice funzione printInFrame in print-in-frame.js:

// In print-in-frame.js

const printInFrame = (size, header) => {
  console.log('*'.repeat(size));
  console.log(header);
  console.log('*'.repeat(size));
};

La funzione accetta un argomento numerico size e un argomento stringa header e stampa quell'intestazione in una cornice di stelle con la dimensione specificata.

Vogliamo usare questo file in due modi:

1. Direttamente dalla riga di comando in questo modo:

~/learn-node $ node print-in-frame 8 Hello

Passando 8 e Hello come argomenti della riga di comando per stampare "Hello" in una cornice di 8 stelle.

2. Con require. Supponendo che il modulo richiesto esporterà la funzione printInFrame, possiamo semplicemente chiamarla:

const print = require('./print-in-frame');

print(5, 'Hey');

Per stampare l'intestazione "Hey" in una cornice di 5 stelle.

Sono due usi diversi. Abbiamo bisogno di un modo per determinare se il file viene eseguito come script autonomo o se è richiesto da altri script.

Qui è dove possiamo usare questa semplice istruzione if:

if (require.main === module) {
  // Il file viene eseguito direttamente (non con require)
}

Quindi possiamo utilizzare questa condizione per soddisfare i requisiti di utilizzo di cui sopra richiamando la funzione printInFrame in modo diverso:

// In print-in-frame.js

const printInFrame = (size, header) => {
  console.log('*'.repeat(size));
  console.log(header);
  console.log('*'.repeat(size));
};

if (require.main === module) {
  printInFrame(process.argv[2], process.argv[3]);
} else {
  module.exports = printInFrame;
}

Quando il file non è richiesto, chiamiamo semplicemente la funzione printInFrame con gli elementi process.argv. Altrimenti, cambiamo semplicemente l'oggetto module.exports in modo che questo sia la funzione stessa printInFrame.

Tutti i moduli verranno memorizzati nella cache

La memorizzazione nella cache è importante da capire. Vorrei usare un semplice esempio per dimostrarlo.

Supponiamo che tu abbia il seguente file ascii-art.js che stampa un'intestazione dall'aspetto interessante:

Vogliamo visualizzare questa intestazione ogni volta che richiediamo il file. Quindi, quando richiediamo il file due volte, vogliamo che l'intestazione venga visualizzata due volte.

require('./ascii-art') // mostrerà l'intestazione.
require('./ascii-art') // non mostrerà l'intestazione.

La second richiesta non mostrerà l'intestazione a causa della memorizzazione nella cache dei moduli. Node memorizza nella cache la prima chiamata e non carica il file nella seconda chiamata.

Possiamo vedere questa cache stampando require.cache dopo la prima richiesta. Il registro della cache è semplicemente un oggetto che ha una proprietà per ogni modulo richiesto. Questi valori di proprietà sono gli oggetti module utilizzati per ogni modulo. Possiamo semplicemente eliminare una proprietà da questo oggetto require.cache per invalidare quella cache. Se lo facciamo, Node ricaricherà il modulo per reinserirlo nella cache.

Tuttavia, questa non è la soluzione più efficiente per questo caso. La soluzione semplice è avvolgere la riga log ascii-art.js con una funzione ed esportare quella funzione. In questo modo, quando richiediamo il file ascii-art.js, otteniamo una funzione che possiamo eseguire per invocare la stampa ogni volta:

require('./ascii-art')() // mostrerà l'intestazione.
require('./ascii-art')() // mostrerà anche l'intestazione.

Questo è tutto ciò che ho per questo argomento. Grazie per aver letto. Alla prossima!

Stai imparando React o Node? Scopri i miei libri:

• Learn React.js by Building Games
• Node.js Beyond the Basics

Le variabili di ambiente sono variabili che vengono impostate al di fuori di un programma, spesso tramite un cloud provider o un sistema operativo.

In Node, le variabili di ambiente sono un ottimo strumento per configurare in modo sicuro e conveniente cose che non cambiano spesso, come URL, chiavi di autenticazione e password.

Come creare variabili d'ambiente

Le variabili di ambiente sono supportate nativamente in Node e sono accessibili tramite l'oggetto env (che è una proprietà dell'oggetto globale process).

Per vederla in azione, puoi creare la tua variabile di ambiente direttamente nel REPL di Node aggiungendo una variabile direttamente all'oggetto process.env.

Ad esempio, per creare una variabile d'ambiente per memorizzare la combinazione sul mio bagaglio potrei assegnare la variabile in questo modo: process.env.LUGGAGE_COMBO=“12345”.

(Una piccola parentesi: le variabili di ambiente sono, per convenzione, generalmente scritte in maiuscolo.)

Sebbene questo sia a puro titolo d'esempio, non userai mai REPL di Node in questo modo in un'app. Per creare variabili di ambiente nella tua app Node, probabilmente vorrai usare un pacchetto come DotEnv.

Come usare DotEnv

DotEnv è un piccolo pacchetto npm che carica automaticamente le variabili di ambiente da un file .env nell'oggetto process.env.

Per utilizzare DotEnv, prima bisogna installarlo utilizzando il comando: npm i dotenv. Quindi nella tua app, richiedi e configura il pacchetto in questo modo: require('dotenv').config().

Tieni presente che alcuni pacchetti come Create React App includono già DotEnv e i provider di servizi cloud potrebbero disporre di metodi diversi per impostare le variabili di ambiente. Quindi assicurati di controllare la documentazione sia per i pacchetti che per provider che stai utilizzando prima di seguire qualsiasi consiglio di questo articolo.

Come creare un file .env

Dopo aver installato e configurato DotEnv, crea un file chiamato .env al livello più alto della struttura dei file. Qui è dove dichiarerai tutte le tue variabili d'ambiente, scritte nel formato  NAME=value . Ad esempio, puoi impostare una variabile di porta su 3000 in questo modo: PORT=3000.

Puoi dichiarare più variabili nel file .env. Ad esempio, puoi impostare variabili di ambiente relative al database come queste:

DB_HOST=localhost
DB_USER=admin
DB_PASSWORD=password

Non è necessario racchiudere le stringhe tra virgolette. DotEnv lo fa automaticamente per te.

Una volta creato questo file, ricorda che non dovresti inviarlo a GitHub poiché può contenere dati sensibili come chiavi di autenticazione e password. Aggiungi il file a .gitignore per evitare di inviarlo accidentalmente a un repository pubblico.

Come accedere alle variabili d'ambiente

Accedere alle tue variabili è semplicissimo! Sono attaccati all'oggetto process.env, quindi puoi accedervi usando il modello process.env.KEY.

Se hai bisogno di modificare il valore di una qualsiasi delle tue variabili d'ambiente, devi solo modificare il file .env.

Ricapitolando

Le variabili di ambiente renderanno il tuo codice più gestibile e più sicuro. Sono facili da configurare con DotEnv e semplici da usare in Node.

Ora che sai come si fa, puoi creare le tue variabili di ambiente per la tua applicazione Node. Divertiti!

Come usare spawn(), exec(), execFile() e fork()

Le prestazioni a singolo thread e non bloccanti in Node.js funzionano alla grande per un singolo processo. Ma alla fine, un processo in una CPU non sarà sufficiente per gestire il crescente carico di lavoro della tua applicazione.

Indipendentemente dalla potenza del tuo server, un singolo thread può supportare solo un carico limitato.

Il fatto che Node.js venga eseguito in un singolo thread non significa che non possiamo sfruttare più processi e, ovviamente, anche più macchine.

L'uso di più processi è il modo migliore per scalare un'applicazione Node. Node.js è progettato per la creazione di applicazioni distribuite con molti nodi. Questo è il motivo per cui si chiama Node . La scalabilità è incorporata nella piattaforma e non è qualcosa a cui inizi a pensare dopo, nel corso della vita di un'applicazione.

Questo articolo è un riassunto di parte del my Pluralsight course about Node.js. Lì copro contenuti simili in formato video in inglese.

Tieni presente che avrai bisogno di una buona conoscenza degli eventi e degli stream di Node.js prima di leggere questo articolo. Se non l'hai già fatto, ti consiglio di leggere questi altri due articoli prima di leggere questo:

Understanding Node.js Event-Driven Architecture
Most of Node’s objects — like HTTP requests, responses, and streams — implement the EventEmitter module so they can…

Streams: Everything you need to know
Node.js streams have a reputation for being hard to work with, and even harder to understand. Well I’ve got good news…

Il modulo Child Process

Possiamo facilmente far girare un child process usando il modulo di Node child_process e quei child process possono facilmente comunicare tra loro con un sistema di messaggistica.

Il modulo child_process ci consente di accedere alle funzionalità del sistema operativo eseguendo qualsiasi comando di sistema all'interno di un processo figlio.

Possiamo controllare il flusso di input del child process e ascoltare il suo flusso di output. Possiamo anche controllare gli argomenti da passare al comando del sistema operativo sottostante e possiamo fare tutto ciò che vogliamo con l'output di quel comando. Possiamo, ad esempio, reindirizzare l'output di un comando come input a un altro (proprio come facciamo in Linux) poiché tutti gli input e gli output di questi comandi possono essere a noi disponibili utilizzando Node.js streams .

Nota che gli esempi che userò in questo articolo sono tutti basati su Linux. Su Windows, devi cambiare questi i comandi con i loro corrispettivi.

Esistono quattro modi diversi per creare un processo figlio in Node: spawn(), fork(), exec()e execFile().

Vedremo le differenze tra queste quattro funzioni e quando usarle.

Child Process generati

La funzione spawn (generatore) lancia un comando in un nuovo processo e possiamo usarla per passare a quel comando qualsiasi argomento. Ad esempio, ecco il codice per generare un nuovo processo che eseguirà il comando pwd.

const { spawn } = require('child_process');

const child = spawn('pwd');

Estraiamo semplicemente la funzione spawn dal modulo child_process e la eseguiamo con il comando del sistema operativo come primo argomento.

Il risultato dell'esecuzione della funzione spawn (l'oggetto child di sopra) è un'istanza ChildProcess che implementa l' API EventEmitter . Ciò significa che possiamo registrare direttamente i gestori per gli eventi su questo oggetto child. Ad esempio, possiamo fare qualcosa quando il processo child esce registrando un gestore per l'evento exit:

child.on('exit', function (code, signal) {
  console.log('child process exited with ' +
              `code ${code} and signal ${signal}`);
});

Il gestore sopra ci fornisce il code di uscita per il child process e il signal, se presente, che è stato utilizzato per terminare il processo figlio. Questa variabile signal è nulla quando il child process esce normalmente.

Gli altri eventi per i quali possiamo registrare i gestori per le istanze di ChildProcess sono disconnect, error, close e message.

• L'evento disconnect viene emesso quando il processo genitore chiama manualmente la funzione child.disconnect.
• L'evento error viene emesso se il processo non può essere generato o terminato.
• L'evento close viene emesso quando i flussi stdio di un processo figlio vengono chiusi.
• L'evento message è quello più importante. Viene emesso quando il processo figlio utilizza la funzione process.send() per inviare messaggi. Questo è il modo in cui i processi genitore/figlio possono comunicare tra loro. Vedremo dopo un esempio.

Ogni processo figlio ottiene anche i tre flussi standard stdio, a cui possiamo accedere utilizzando child.stdin, child.stdout e child.stderr.

Quando questi flussi vengono chiusi, il processo figlio che li stava utilizzando emetterà l'evento close. Questo evento close è diverso dall'evento exit perché più processi figlio potrebbero condividere gli stessi flussi stdio e quindi l'uscita di un processo figlio non significa che i canali siano stati chiusi.

Poiché tutti i flussi sono emettitori di eventi, possiamo ascoltare eventi diversi su quei flussi stdio collegati a ogni processo figlio. A differenza di un processo normale, tuttavia, in un processo figlio, i flussi stdout/ stderr sono flussi leggibili mentre il flusso stdin è scrivibile. Questo è fondamentalmente l'inverso di quei tipi che si trovano in un processo principale. Gli eventi che possiamo usare per quei flussi sono quelli standard. Soprattutto, sui flussi leggibili, possiamo ascoltare l'evento data, che avrà l'output del comando o qualsiasi errore riscontrato durante l'esecuzione del comando:

child.stdout.on('data', (data) => {
  console.log(`child stdout:\n${data}`);
});

child.stderr.on('data', (data) => {
  console.error(`child stderr:\n${data}`);
});

I due gestori precedenti registreranno entrambi i casi stdout e stderr nel processo principale . Quando eseguiamo la funzione spawn di sopra, l'output del comando pwd viene stampato e il processo figlio esce con code 0, il che significa che non si è verificato alcun errore.

Possiamo passare argomenti al comando eseguito dalla funzione spawn utilizzando il secondo argomento della stessa funzione spawn, che è un array di tutti gli argomenti da passare al comando. Ad esempio, per eseguire il comandofind sulla directory corrente con un argomento -type f (solo per elencare i file), possiamo fare:

const child = spawn('find', ['.', '-type', 'f']);

Se si verifica un errore durante l'esecuzione del comando, ad esempio, gli diamo da trovare una destinazione non valida, il gestore dell'evento child.stderr data verrà attivato e il gestore dell'evento exit segnalerà 1 come codice di uscita, che indica che si è verificato un errore. I valori di errore dipendono dal sistema operativo e dal tipo di errore.

Un processo figlio stdin è un flusso scrivibile. Possiamo usarlo per inviare un comando di input. Proprio come qualsiasi flusso scrivibile, il modo più semplice per usarlo è utilizzare la funzione pipe. Convogliamo semplicemente un flusso leggibile in un flusso scrivibile. Poiché il processo principale stdin è un flusso leggibile, possiamo convogliarlo in un flusso stdin del processo figlio. Per esempio:

const { spawn } = require('child_process');

const child = spawn('wc');

process.stdin.pipe(child.stdin)

child.stdout.on('data', (data) => {
  console.log(`child stdout:\n${data}`);
});

Nell'esempio sopra, il processo figlio richiama il comando wc, che conta righe, parole e caratteri in Linux. Quindi convogliamo il processo principale stdin (che è un flusso leggibile) nel processo figlio stdin (che è un flusso scrivibile). Il risultato di questa combinazione è che otteniamo una modalità di input standard in cui possiamo digitare qualcosa e quando premiamo Ctrl+D, ciò che abbiamo digitato verrà utilizzato come input del comando wc.

Possiamo anche convogliare l'input/output standard di più processi l'uno sull'altro, proprio come possiamo fare con i comandi Linux. Ad esempio, possiamo reindirizzare il stdout del comando find allo stdin del comando wc per contare tutti i file nella directory corrente:

const { spawn } = require('child_process');

const find = spawn('find', ['.', '-type', 'f']);
const wc = spawn('wc', ['-l']);

find.stdout.pipe(wc.stdin);

wc.stdout.on('data', (data) => {
  console.log(`Number of files ${data}`);
});

Ho aggiunto l'argomento -l al comando wc per fargli contare solo le righe. Quando viene eseguito, il codice sopra produrrà un conteggio di tutti i file in tutte le directory dentro quella corrente.

La sintassi della shell e la funzione exec

Per impostazione predefinita, la funzione spawn non crea una shell per eseguire il comando che gli passiamo. Questo la rende leggermente più efficiente della funzione exec, che crea una shell. La funzione exec ha un'altra grande differenza. Memorizza l'output generato dal comando e passa l'intero valore di output a una funzione di callback (invece di utilizzare i flussi, che è ciò che fa invece spawn).

Ecco l'esempio precedente find | wc implementato con una funzione exec.

const { exec } = require('child_process');

exec('find . -type f | wc -l', (err, stdout, stderr) => {
  if (err) {
    console.error(`exec error: ${err}`);
    return;
  }

  console.log(`Number of files ${stdout}`);
});

Poiché la funzione exec utilizza una shell per eseguire il comando, possiamo usare la sintassi della shell direttamente qui facendo uso della capacità pipe di shell.

Nota che l'uso della sintassi della shell comporta un rischio per la sicurezza se stai eseguendo qualsiasi tipo di input dinamico fornito esternamente. Un utente può semplicemente eseguire un attacco tramite l'iniezione di comandi utilizzando caratteri della sintassi della shell come ; e $ (ad esempio, command + ’; rm -rf ~’)

La funzione exec memorizza nel buffer l'output e lo passa alla funzione di callback (il secondo argomento di exec) come argomento stdout. Questo argomento stdout è l'output del comando che vogliamo stampare.

La funzione exec è una buona scelta se è necessario utilizzare la sintassi della shell e se la dimensione dei dati prevista dal comando è piccola. (Ricorda, exec eseguirà il buffering di tutti i dati in memoria prima di restituirli.)

La funzione spawn è la scelta migliore quando la dimensione dei dati prevista dal comando è grande, perché i dati verranno trasmessi in streaming con gli oggetti IO standard.

Possiamo fare in modo che il processo figlio generato erediti gli oggetti IO standard dei suoi genitori, se lo desideriamo, ma anche, cosa più importante, possiamo fare in modo che la funzione spawn utilizzi anche la sintassi della shell. Ecco lo stesso comando find | wc implementato con la funzione spawn:

const child = spawn('find . -type f | wc -l', {
  stdio: 'inherit',
  shell: true
});

A causa dell'opzione di sopra stdio: 'inherit', quando eseguiamo il codice, il processo figlio eredita stdin, stdout e stderr dal processo principale. Ciò fa sì che i gestori di eventi dei dati del processo figlio vengano attivati ​​nel canale process.stdout, facendo in modo che lo script emetta immediatamente il risultato.

Grazie all'opzione precedente shell: true, siamo stati in grado di utilizzare la sintassi della shell nel comando precedente, proprio come abbiamo fatto con exec. Ma con questo codice, otteniamo comunque il vantaggio dello streaming di dati che la funzione spawn ci offre. Questo è davvero il meglio di entrambi i mondi.

Ci sono alcune altre buone opzioni che possiamo usare nell'ultimo argomento delle funzioni child_process oltre a shell e stdio. Possiamo, ad esempio, usare l'opzione cwd per cambiare la directory di lavoro dello script. Infatti, ecco lo stesso esempio di conteggio di tutti i file eseguito con una funzione spawn che utilizza una shell e con una directory di lavoro impostata nella mia cartella Downloads. L'opzione cwd qui farà sì che lo script conteggi tutti i file che ho in ~/Downloads:

const child = spawn('find . -type f | wc -l', {
  stdio: 'inherit',
  shell: true,
  cwd: '/Users/samer/Downloads'
});

Un'altra opzione che possiamo usare è l'opzione env per specificare le variabili di ambiente che saranno visibili al nuovo processo figlio. L'impostazione predefinita per questa opzione è process.env che fornisce a qualsiasi comando l'accesso all'ambiente del processo corrente. Se vogliamo sovrascrivere quel comportamento, possiamo semplicemente passare un oggetto vuoto all'opzione env o nuovi valori da considerare come le uniche variabili d'ambiente:

const child = spawn('echo $ANSWER', {
  stdio: 'inherit',
  shell: true,
  env: { ANSWER: 42 },
});

Il comando echo di sopra non ha accesso alle variabili di ambiente del processo padre. Ad esempio, non può accedere a $HOME, ma può accedere a $ANSWER perché è stata passata come variabile di ambiente personalizzata tramite l'opzione env.

Un'ultima importante opzione del processo figlio da spiegare qui è l'opzione detached, che fa sì che il processo figlio venga eseguito indipendentemente dal suo processo padre.

Supponendo di avere un file timer.js che mantiene occupato il ciclo degli eventi:

setTimeout(() => {  
  // keep the event loop busy
}, 20000);

Possiamo eseguirlo in background usando l'opzione detached:

const { spawn } = require('child_process');

const child = spawn('node', ['timer.js'], {
  detached: true,
  stdio: 'ignore'
});

child.unref();

L'esatto comportamento dei processi figli distaccati dipende dal sistema operativo. Su Windows, avrà la propria finestra della console mentre su Linux il processo figlio distaccato sarà nominato leader di un nuovo gruppo di processi e sessione.

Se la funzione unref viene chiamata sul processo distaccato, il processo padre può uscire indipendentemente dal figlio. Questo può essere utile se il figlio sta eseguendo un processo di lunga durata, ma per mantenerlo in esecuzione in background le configurazioni stdio del figlio devono anch'esse essere indipendenti dal genitore.

L'esempio sopra eseguirà uno script del nodo ( timer.js) in background staccando e ignorando anche i suoi descrittori di file stdio del padre in modo che il genitore possa terminare mentre il figlio continuerà a essere eseguito in background.

La funzione execFile

Se devi eseguire un file senza usare una shell, la funzione execFile è ciò di cui hai bisogno. Si comporta esattamente come la funzione exec, ma non usa una shell, il che la rende un po' più efficiente. Su Windows, alcuni file non possono essere eseguiti da soli, come i file .bat o .cmd. Questi file non possono essere eseguiti con execFile e per eseguirli con exec o spawn è necessario che la shell sia impostata su true.

Le funzioni *Sync

Le funzioni spawn, exec, ed execFile del modulo child_process hanno anche versioni bloccanti sincrone che attenderanno fino all'uscita del processo figlio.

const { 
  spawnSync, 
  execSync, 
  execFileSync,
} = require('child_process');

Tali versioni sincrone sono potenzialmente utili quando si tenta di semplificare le attività di scripting o qualsiasi attività di elaborazione all'avvio, ma in caso contrario dovrebbero essere evitate.

La funzione fork()

La funzione fork è una variante della funzione spawn per la generazione di nodi di processi. La più grande differenza tra spawn e fork è che viene stabilito un canale di comunicazione con il processo figlio quando si utilizza fork, quindi possiamo utilizzare la funzione send sul processo fork (biforcato) insieme allo stesso oggetto globale process per scambiare messaggi tra il processo padre e il processo fork. Lo facciamo attraverso l'interfaccia EventEmitter del modulo. Ecco un esempio:

Il file principale parent.js,:

const { fork } = require('child_process');

const forked = fork('child.js');

forked.on('message', (msg) => {
  console.log('Message from child', msg);
});

forked.send({ hello: 'world' });

Il file figlio child.js,:

process.on('message', (msg) => {
  console.log('Message from parent:', msg);
});

let counter = 0;

setInterval(() => {
  process.send({ counter: counter++ });
}, 1000);

Nel file padre di sopra, eseguiamo il fork di child.js(che eseguirà il file con il comando node) e quindi ascoltiamo l'evento message. L'evento message verrà emesso ogni volta che il figlio utilizza process.send, cosa che stiamo facendo ogni secondo.

Per passare i messaggi dal genitore al figlio, possiamo eseguire la funzione send sull'oggetto fork stesso e quindi, nello script figlio, possiamo ascoltare l'evento message sull'oggetto globale process.

Quando si esegue il file parent.js di sopra, questo invierà prima l'oggetto { hello: 'world' } che verrà stampato dal processo figlio il quale invierà un valore contatore incrementato ogni secondo, che verrà stampato dal processo padre.

Facciamo un esempio più pratico sulla funzione fork.

Supponiamo di avere un server http che gestisce due endpoint. Uno di questi endpoint ( /compute di sotto) è computazionalmente costoso e richiederà alcuni secondi per essere completato. Possiamo simulare ciò usando un lungo ciclo for:

const http = require('http');

const longComputation = () => {
  let sum = 0;
  for (let i = 0; i < 1e9; i++) {
    sum += i;
  };
  return sum;
};

const server = http.createServer();

server.on('request', (req, res) => {
  if (req.url === '/compute') {
    const sum = longComputation();
    return res.end(`Sum is ${sum}`);
  } else {
    res.end('Ok')
  }
});

server.listen(3000);

Questo programma ha un grosso problema; quando viene richiesto l'endpoint /compute , il server non sarà in grado di gestire altre richieste perché il ciclo di eventi è occupato con la lunga operazione del ciclo for.

Ci sono alcuni modi con cui possiamo risolvere questo problema a seconda della natura dell'operazione lunga, ma una soluzione che funziona per tutte le operazioni è semplicemente spostare l'operazione di calcolo in un altro processo usando fork.

Per prima cosa spostiamo l'intera funzione longComputation nel proprio file e facciamo in modo che invochi quella funzione quando richiesto tramite un messaggio dal processo principale:

In un nuovo file compute.js:

const longComputation = () => {
  let sum = 0;
  for (let i = 0; i < 1e9; i++) {
    sum += i;
  };
  return sum;
};

process.on('message', (msg) => {
  const sum = longComputation();
  process.send(sum);
});

Ora, invece di eseguire la lunga operazione nel ciclo di eventi del processo principale, possiamo fare il fork del file compute.js e utilizzare l'interfaccia dei messaggi per comunicare i messaggi tra il server e il processo biforcato.

const http = require('http');
const { fork } = require('child_process');

const server = http.createServer();

server.on('request', (req, res) => {
  if (req.url === '/compute') {
    const compute = fork('compute.js');
    compute.send('start');
    compute.on('message', sum => {
      res.end(`Sum is ${sum}`);
    });
  } else {
    res.end('Ok')
  }
});

server.listen(3000);

Ora con il codice sopra, quando si verifica una richiesta /compute, inviamo semplicemente un messaggio al processo biforcato per avviare l'esecuzione dell'operazione lunga. Il ciclo di eventi del processo principale non verrà bloccato.

Una volta che il processo fork ha terminato con quella lunga operazione, può inviare il suo risultato al processo padre usando process.send.

Nel processo padre, ascoltiamo l'evento message sul processo figlio biforcato. Quando avremo quell'evento, avremo un valore sum pronto da inviare all'utente richiedente su http.

Il codice sopra è, ovviamente, limitato dal numero di processi che possiamo biforcare, ma quando lo eseguiamo e richiediamo l'endpoint di calcolo lungo su http, il server principale non è affatto bloccato e può accettare ulteriori richieste.

Il modulo cluster di Node, che è l'argomento del mio prossimo articolo, si basa su questa idea di fork del processo figlio e bilanciamento del carico delle richieste tra i molti fork che possiamo creare su qualsiasi sistema.

Questo è tutto per questo argomento. Grazie per aver letto! Alla prossima!

Imparare React o Node? Scopri i miei libri:

• Impara React.js costruendo giochi
• Node.js oltre le basi