Come verificare se uno script è in esecuzione in Node.js?

Ho uno script che sto richiedendo da uno script Node.js, che voglio mantenere indipendente il motore JavaScript.

Ad esempio, voglio fare exports.x = y;solo se funziona sotto Node.js. Come posso eseguire questo test?

Quando ho pubblicato questa domanda, non sapevo che la funzione dei moduli Node.js fosse basata su CommonJS .

Per l'esempio specifico che ho dato, una domanda più accurata sarebbe stata:

Come può uno script dire se è stato richiesto come modulo CommonJS?

Cercando il supporto CommonJS , ecco come funziona la libreria Underscore.js :

Modifica: alla domanda aggiornata:

(function () {

    // Establish the root object, `window` in the browser, or `global` on the server.
    var root = this; 

    // Create a reference to this
    var _ = new Object();

    var isNode = false;

    // Export the Underscore object for **CommonJS**, with backwards-compatibility
    // for the old `require()` API. If we're not in CommonJS, add `_` to the
    // global object.
    if (typeof module !== 'undefined' && module.exports) {
            module.exports = _;
            root._ = _;
            isNode = true;
    } else {
            root._ = _;
    }
})();

L'esempio qui mantiene il modello del modulo.

Bene, non esiste un modo affidabile per rilevare l'esecuzione in Node.js poiché ogni sito Web potrebbe facilmente dichiarare le stesse variabili, poiché non esiste window oggetto in Node.js per impostazione predefinita, puoi fare il contrario e verificare se stai eseguendo all'interno di un Browser.

Questo è quello che uso per le librerie che dovrebbero funzionare sia in un browser che in Node.js:

if (typeof window === 'undefined') {
    exports.foo = {};

} else {
    window.foo = {};
}

Potrebbe comunque esplodere nel caso in cui windowsia definito in Node.js ma non c'è alcun buon motivo per farlo, dato che dovresti esplicitamente lasciare fuori varo impostare la proprietà sulglobal sull'oggetto.

MODIFICARE

Per rilevare se il tuo script è stato richiesto come modulo CommonJS, non è ancora facile. L'unica cosa che commonJS specifica è che A: I moduli saranno inclusi tramite una chiamata alla funzione requiree B: I moduli esportano le cose tramite proprietà exportssull'oggetto. Ora come viene implementato questo è lasciato al sistema sottostante. Node.js racchiude il contenuto del modulo in una funzione anonima:

function (exports, require, module, __filename, __dirname) { 

Vedi: https://github.com/ry/node/blob/master/src/node.js#L325

Ma non provare a rilevarlo tramite alcune arguments.callee.toString()cose folli , invece usa semplicemente il mio codice di esempio sopra il quale controlla il browser. Node.js è un ambiente molto più pulito, quindi è improbabile che windowvenga dichiarato lì.

Al momento mi sono imbattuto in un rilevamento errato di Node che non è a conoscenza dell'ambiente Node in Electron a causa di un rilevamento delle funzioni fuorviante. Le seguenti soluzioni identificano esplicitamente l'ambiente di processo.

Identifica solo Node.js

(typeof process !== 'undefined') && (process.release.name === 'node')

Questo scoprirà se stai eseguendo un processo Node, poiché process.releasecontiene i "metadati relativi all'attuale versione [Node-]".

Dopo la generazione di io.js, il valore di process.release.namepuò anche diventare io.js(vedere il processo-doc ). Per rilevare correttamente un ambiente pronto per il nodo, suppongo che si dovrebbe controllare come segue:

Identificare il nodo (> = 3.0.0) o io.js

(typeof process !== 'undefined') &&
(process.release.name.search(/node|io.js/) !== -1)

Questa affermazione è stata testata con Nodo 5.5.0, Electron 0.36.9 (con Nodo 5.1.1) e Chrome 48.0.2564.116.

Identificare il nodo (> = 0.10.0) o io.js

(typeof process !== 'undefined') &&
(typeof process.versions.node !== 'undefined')

Il commento di @ daluege mi ha ispirato a pensare a una prova più generale. Questo dovrebbe funzionare da Node.js> = 0.10 . Non ho trovato un identificatore univoco per le versioni precedenti.

Ps: sto postando quella risposta qui poiché la domanda mi porta qui, anche se l'OP stava cercando una risposta a una domanda diversa.

Il problema con il tentativo di capire in quale ambiente è in esecuzione il tuo codice è che qualsiasi oggetto può essere modificato e dichiarato rendendo quasi impossibile capire quali oggetti sono nativi per l'ambiente e quali sono stati modificati dal programma.

Tuttavia, ci sono alcuni trucchi che possiamo usare per capire con certezza l'ambiente in cui ti trovi.

Iniziamo con la soluzione generalmente accettata utilizzata nella libreria di sottolineatura:

typeof module !== 'undefined' && module.exports

Questa tecnica è in realtà perfettamente valida per il lato server, poiché quando requireviene chiamata la funzione, reimposta l' thisoggetto su un oggetto vuoto e lo ridefinisce modulenuovamente per te, il che significa che non devi preoccuparti di manomissioni esterne. Finché il tuo codice è caricato require, sei al sicuro.

Tuttavia, questo cade a pezzi sul browser, poiché chiunque può facilmente definirlo moduleper far sembrare che sia l'oggetto che stai cercando. Da un lato questo potrebbe essere il comportamento desiderato, ma determina anche quali variabili l'utente della libreria può utilizzare nell'ambito globale. Forse qualcuno vuole usare una variabile con il nome moduleche ha exportsal suo interno per un altro uso. È improbabile, ma chi siamo noi per giudicare quali variabili qualcun altro può usare, solo perché un altro ambiente utilizza quel nome di variabile?

Il trucco, tuttavia, è che se stiamo assumendo che il tuo script sia caricato nell'ambito globale (che sarà se viene caricato tramite un tag di script) una variabile non può essere riservata in una chiusura esterna, perché il browser non lo consente . Ora ricorda nel nodo, l' thisoggetto è un oggetto vuoto, eppure la modulevariabile è ancora disponibile. Questo perché è dichiarato in una chiusura esterna. Quindi possiamo quindi correggere il controllo di sottolineatura aggiungendo un controllo extra:

this.module !== module

Con questo, se qualcuno dichiara modulenell'ambito globale nel browser, verrà inserito thisnell'oggetto, il che provocherà il fallimento del test, poiché this.modulesarà lo stesso oggetto del modulo. Sul nodo, this.modulenon esiste ed moduleesiste all'interno di una chiusura esterna, quindi il test avrà esito positivo, poiché non sono equivalenti.

Pertanto, il test finale è:

typeof module !== 'undefined' && this.module !== module

Nota: sebbene ciò ora consenta alla modulevariabile di essere utilizzata liberamente nell'ambito globale, è comunque possibile aggirarla nel browser creando una nuova chiusura e dichiarando al suo moduleinterno, quindi caricando lo script all'interno di quella chiusura. A quel punto l'utente sta replicando completamente l'ambiente del nodo e, si spera, sa cosa sta facendo e sta cercando di fare uno stile di nodo richiesto. Se il codice viene chiamato in un tag script, sarà comunque al sicuro da eventuali nuove chiusure esterne.

Quanto segue funziona nel browser a meno che non sia stato intenzionalmente sabotato esplicitamente:

if(typeof process === 'object' && process + '' === '[object process]'){
    // is node
}
else{
    // not node
}

Bam.

Ecco un bel modo per farlo anche:

const isBrowser = this.window === this;

Questo funziona perché nei browser la variabile globale "questa" ha un riferimento personale chiamato "finestra". Questo riferimento personale non esiste in Nodo.

• Nel browser "questo" è un riferimento all'oggetto globale, chiamato "finestra".
• Nel nodo 'this' è un riferimento all'oggetto module.exports.
  • 'questo' non lo è un riferimento all'oggetto globale Node, chiamato 'global'.
  • 'this' non è un riferimento allo spazio di dichiarazione delle variabili del modulo.

Per interrompere il controllo del browser suggerito sopra, dovresti fare qualcosa di simile al seguente

this.window = this;

prima di eseguire il controllo.

Ancora un altro rilevamento ambientale :

(Significato: la maggior parte delle risposte qui sono a posto.)

function isNode() {
    return typeof global === 'object'
        && String(global) === '[object global]'
        && typeof process === 'object'
        && String(process) === '[object process]'
        && global === global.GLOBAL // circular ref
        // process.release.name cannot be altered, unlike process.title
        && /node|io\.js/.test(process.release.name)
        && typeof setImmediate === 'function'
        && setImmediate.length === 4
        && typeof __dirname === 'string'
        && Should I go on ?..
}

Un po 'paranoico vero? Puoi renderlo più dettagliato controllando più globuli .

Ma NON !.

Tutti questi sopra possono essere simulati / simulati comunque.

Ad esempio per falsificare l' globaloggetto:

global = {
    toString: function () {
        return '[object global]';
    },
    GLOBAL: global,
    setImmediate: function (a, b, c, d) {}
 };
 setImmediate = function (a, b, c, d) {};
 ...

Questo non verrà attaccato all'oggetto globale originale del Nodo ma verrà attaccato windowall'oggetto in un browser. Quindi implica che sei in Node env all'interno di un browser.

La vita è breve!

Ci preoccupiamo se il nostro ambiente è falso? Succederebbe quando uno stupido sviluppatore dichiarasse chiamata una variabile globaleglobal nell'ambito globale. O qualche sviluppatore malvagio inietta codice nel nostro ambiente in qualche modo.

Potremmo impedire l'esecuzione del nostro codice quando lo rileviamo, ma molte altre dipendenze della nostra app potrebbero essere coinvolte in questo. Quindi alla fine il codice si romperà. Se il tuo codice è abbastanza buono, non dovresti preoccuparti di ogni errore sciocco che avrebbe potuto essere fatto da altri.

E allora?

Se si rivolge a 2 ambienti: Browser e Nodo;
"use strict"; e controlla semplicemente per windowo global; e indica chiaramente che nei documenti che il tuo codice supporta solo questi ambienti. Questo è tutto!

var isBrowser = typeof window !== 'undefined'
    && ({}).toString.call(window) === '[object Window]';

var isNode = typeof global !== "undefined" 
    && ({}).toString.call(global) === '[object global]';

Se possibile per il tuo caso d'uso; invece del rilevamento dell'ambiente; eseguire il rilevamento sincrono delle funzioni all'interno di un blocco try / catch. (l'esecuzione richiederà alcuni millisecondi).

per esempio

function isPromiseSupported() {
    var supported = false;
    try {
        var p = new Promise(function (res, rej) {});
        supported = true;
    } catch (e) {}
    return supported;
}

La maggior parte delle soluzioni proposte può effettivamente essere simulata. Un modo affidabile è verificare la Classproprietà interna dell'oggetto globale usando il Object.prototype.toString. La classe interna non può essere falsificata in JavaScript:

var isNode = 
    typeof global !== "undefined" && 
    {}.toString.call(global) == '[object global]';

Cosa succede ad usare l'oggetto processo e controllo execPath per node?

process.execPath

Questo è il percorso assoluto dell'eseguibile che ha avviato il processo.

Esempio:

/ Usr / local / bin / node

Come può uno script dire se è stato richiesto come modulo commonjs?

Correlati: per verificare se è stato richiesto come modulo vs eseguire direttamente nel nodo, è possibile verificare require.main !== module. http://nodejs.org/docs/latest/api/modules.html#accessing_the_main_module

Ecco la mia variazione su quanto sopra:

(function(publish) {
    "use strict";

    function House(no) {
        this.no = no;
    };

    House.prototype.toString = function() {
        return "House #"+this.no;
    };

    publish(House);

})((typeof module == 'undefined' || (typeof window != 'undefined' && this == window))
    ? function(a) {this["House"] = a;}
    : function(a) {module.exports = a;});

Per usarlo, modifichi "House" sull'ultima riga in modo che sia qualsiasi cosa tu voglia che il nome del modulo sia nel browser e pubblichi qualunque cosa tu voglia che sia il valore del modulo (di solito un costruttore o un oggetto letterale ).

Nei browser l'oggetto globale è window e ha un riferimento a se stesso (c'è una finestra.window che è == window). Mi sembra improbabile che ciò accada a meno che tu non sia in un browser o in un ambiente che vuole farti credere di essere in un browser. In tutti gli altri casi, se viene dichiarata una variabile 'modulo' globale, la utilizza in caso contrario utilizza l'oggetto globale.

Sto usando processper verificare node.js in questo modo

if (typeof(process) !== 'undefined' && process.version === 'v0.9.9') {
  console.log('You are running Node.js');
} else {
  // check for browser
}

o

if (typeof(process) !== 'undefined' && process.title === 'node') {
  console.log('You are running Node.js');
} else {
  // check for browser
}

Documentato qui

Al momento della stesura di questo articolo, questa risposta è più un'opzione "coming soon", visto che sfrutta le nuovissime funzionalità di JavaScript.

const runtime = globalThis.process?.release?.name || 'not node'
console.log(runtime)

Il runtimevalore sarà nodeo not node.

Come accennato, questo si basa su alcune nuove funzionalità JavaScript. globalThisè una funzionalità finalizzata nelle specifiche ECMAScript 2020. Incatenamento facoltativo / coalescenza nulla (la ?parte diglobalThis.process?.release?.name ) è supportata nel motore V8, fornito con Chrome 80. A partire dal 4/8/2020, questo codice funzionerà nel browser ma non funzionerà in Nodo poiché il ramo Nodo 13 utilizza V8 7.9.xxx. Credo che il nodo 14 (che dovrebbe essere rilasciato il 21/04/2020) dovrebbe usare V8 8.x +.

Questo approccio prevede una buona dose delle attuali restrizioni. Però; il ritmo con cui vengono rilasciati i browser / nodo, alla fine sarà un one-liner affidabile.

Node.js ha un processoggetto, quindi finché non hai altri script da creare processPuoi usarlo per determinare se il codice viene eseguito su Node.

var isOnNodeJs = false;
if(typeof process != "undefined") {
  isOnNodeJs = true;
}

if(isOnNodeJs){
  console.log("you are running under node.js");
}
else {
  console.log("you are NOT running under node.js");
}

Questo è un modo abbastanza sicuro e diretto per assicurare la compatibilità tra javascript lato server e lato client, che funzionerà anche con browserify, RequireJS o CommonJS incluso lato client:

(function(){

  // `this` now refers to `global` if we're in NodeJS
  // or `window` if we're in the browser.

}).call(function(){
  return (typeof module !== "undefined" &&
    module.exports &&
    typeof window === 'undefined') ?
    global : window;
}())

Modifica : per quanto riguarda la tua domanda aggiornata: "Come può uno script dire se è stato richiesto come modulo commonjs?" Non penso che possa. Puoi controllare se exportsè un oggetto ( if (typeof exports === "object")), poiché la specifica richiede che sia fornita ai moduli, ma tutto ciò che ti dice è che ... exportsè un oggetto. :-)

Risposta originale:

Sono sicuro che ci sia un simbolo specifico per NodeJS ( EventEmitter, forse no, devi usare requireper ottenere il modulo eventi; vedi sotto ) che potresti controllare, ma come ha detto David, idealmente stai meglio a rilevare la funzione (piuttosto rispetto all'ambiente) se ha senso farlo.

Aggiornamento : forse qualcosa del tipo:

if (typeof require === "function"
    && typeof Buffer === "function"
    && typeof Buffer.byteLength === "function"
    && typeof Buffer.prototype !== "undefined"
    && typeof Buffer.prototype.write === "function") {

Ma questo ti dice solo che sei in un ambiente con requirequalcosa di molto simile a quello di NodeJS Buffer. :-)

const isNode =
  typeof process !== 'undefined' &&
  process.versions != null &&
  process.versions.node != null;

Dalla fonte del pacchetto di debug:

const isBrowser = typeof process === 'undefined' || process.type === 'renderer' || process.browser === true || process.__nwjs

https://github.com/visionmedia/debug/blob/master/src/index.js#L6

Prendi la fonte di node.js e modificala per definire una variabile come runningOnNodeJS. Controlla quella variabile nel tuo codice.

Se non puoi avere la tua versione privata di node.js, apri una richiesta di funzionalità nel progetto. Chiedi che definiscano una variabile che ti dia la versione di node.js in cui stai eseguendo. Quindi controlla quella variabile.

Post molto vecchio, ma l'ho risolto semplicemente racchiudendo le dichiarazioni richieste in un tentativo di cattura

try {
     var fs = require('fs')
} catch(e) {
     alert('you are not in node !!!')
}