Jak sprawdzić, czy skrypt działa w Node.js?

Mam skrypt, którego potrzebuję ze skryptu Node.js, który chcę, aby silnik JavaScript był niezależny.

Na przykład chcę to zrobić exports.x = y;tylko wtedy, gdy działa w Node.js. Jak mogę przeprowadzić ten test?

Pisząc to pytanie, nie wiedziałem, że funkcja modułów Node.js jest oparta na CommonJS .

W przypadku konkretnego przykładu, który podałem, dokładniejsze pytanie brzmiałoby:

W jaki sposób skrypt może stwierdzić, czy był wymagany jako moduł CommonJS?

Szukając wsparcia CommonJS , robi to biblioteka Underscore.js :

Edytuj: do zaktualizowanego pytania:

(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._ = _;
    }
})();

Przykład tutaj zachowuje wzorzec Module.

Cóż, nie ma niezawodnego sposobu na wykrycie działania w Node.js, ponieważ każda witryna może łatwo zadeklarować te same zmienne, ale ponieważ windowdomyślnie nie ma obiektu w Node.js, możesz przejść na odwrót i sprawdzić, czy działasz w Przeglądarka.

Oto, czego używam w przypadku bibliotek, które powinny działać zarówno w przeglądarce, jak i pod Node.js:

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

} else {
    window.foo = {};
}

Może nadal wybuchnąć w przypadku, gdy windowjest to zdefiniowane w Node.js, ale nie ma dobrego powodu, aby ktoś to zrobił, ponieważ jawnie musiałbyś opuścić varlub ustawić właściwość globalobiektu.

EDYTOWAĆ

Aby wykryć, czy Twój skrypt był wymagany jako moduł CommonJS, znowu nie jest to łatwe. Jedyną rzeczą, którą commonJS określa, jest to, że A: moduły zostaną dołączone poprzez wywołanie funkcji, requirea B: moduły eksportują rzeczy poprzez właściwości exportsobiektu. Teraz, jak to jest zaimplementowane, pozostawiono systemowi bazowemu. Node.js opakowuje zawartość modułu w anonimową funkcję:

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

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

Ale nie próbuj tego wykrywać za pomocą jakichś szalonych arguments.callee.toString()rzeczy, zamiast tego użyj mojego przykładowego kodu powyżej, który sprawdza przeglądarkę. Node.js jest o wiele czystszym środowiskiem, więc jest mało prawdopodobne, że windowzostanie tam zadeklarowany.

Obecnie natknąłem się na niewłaściwe wykrywanie węzła, który nie jest świadomy środowiska węzła w Electron z powodu wprowadzającego w błąd wykrywania funkcji. Poniższe rozwiązania jednoznacznie identyfikują środowisko procesowe.

Zidentyfikuj tylko Node.js.

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

Pozwoli to wykryć, czy pracujesz w procesie Node, ponieważ process.releasezawiera „metadane związane z bieżącą wersją [Node-]”.

Po pojawieniu się io.js wartość process.release.namemoże się również zmienićio.js (zobacz dokumentację procesu ). Aby poprawnie wykryć środowisko gotowe do węzła, należy sprawdzić, co następuje:

Zidentyfikuj węzeł (> = 3.0.0) lub io.js

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

To stwierdzenie zostało przetestowane z Node 5.5.0, Electron 0.36.9 (z Node 5.1.1) i Chrome 48.0.2564.116.

Zidentyfikuj węzeł (> = 0.10.0) lub io.js

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

Komentarz @ daluege zainspirował mnie do rozważenia bardziej ogólnego dowodu. To powinno działać z Node.js> = 0,10 . Nie znalazłem unikalnego identyfikatora dla poprzednich wersji.

Ps: Umieszczam tę odpowiedź tutaj, ponieważ pytanie mnie tutaj prowadzi, chociaż OP szukał odpowiedzi na inne pytanie.

Problem z próbą ustalenia, w jakim środowisku działa twój kod, polega na tym, że każdy obiekt można zmodyfikować i zadeklarować, co sprawia, że ​​ustalenie, które obiekty są natywne dla środowiska, a które zostały zmodyfikowane przez program, jest prawie niemożliwe.

Jest jednak kilka sztuczek, których możemy użyć, aby z całą pewnością dowiedzieć się, w jakim środowisku się znajdujesz.

Zacznijmy od ogólnie przyjętego rozwiązania używanego w bibliotece podkreślników:

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

Ta technika jest w rzeczywistości idealna dla serwera, ponieważ gdy requirewywoływana jest funkcja, resetuje thisobiekt do pustego obiektu i ponownie definiuje moduledla Ciebie, co oznacza, że ​​nie musisz się martwić o jakiekolwiek ingerencje z zewnątrz. Dopóki Twój kod jest załadowany require, jesteś bezpieczny.

Jednak to się rozpada w przeglądarce, ponieważ każdy może łatwo zdefiniować, moduleaby wyglądał, jakby to był obiekt, którego szukasz. Z jednej strony może to być zachowanie, które chcesz, ale określa również, jakich zmiennych użytkownik biblioteki może używać w zakresie globalnym. Może ktoś chce użyć zmiennej z nazwą module, która się exportsw niej znajduje, do innego użytku. Jest to mało prawdopodobne, ale kim jesteśmy, aby oceniać, jakich zmiennych może używać ktoś inny, tylko dlatego, że inne środowisko używa tej nazwy zmiennej?

Sztuczka polega jednak na tym, że jeśli założymy, że twój skrypt jest ładowany w zasięgu globalnym (co będzie, jeśli będzie ładowany przez tag skryptu), zmienna nie może być zarezerwowana w zewnętrznym zamknięciu, ponieważ przeglądarka na to nie pozwala . Teraz pamiętaj, że w węźle thisobiekt jest pustym obiektem, ale modulezmienna jest nadal dostępna. To dlatego, że jest zadeklarowany w zewnętrznym zamknięciu. Więc możemy następnie naprawić kontrolę podkreślenia, dodając dodatkową kontrolę:

this.module !== module

Dzięki temu, jeśli ktoś zadeklaruje modulew zasięgu globalnym w przeglądarce, zostanie on umieszczony w thisobiekcie, co spowoduje niepowodzenie testu, ponieważ this.modulebędzie to ten sam obiekt co module. W węźle this.modulenie istnieje i moduleistnieje w zewnętrznym zamknięciu, więc test powiedzie się, ponieważ nie są równoważne.

Tak więc ostateczny test to:

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

Uwaga: Chociaż pozwala to teraz na moduleswobodne używanie zmiennej w zakresie globalnym, nadal można to ominąć w przeglądarce, tworząc nowe zamknięcie i deklarując modulew nim, a następnie ładując skrypt w tym zamknięciu. W tym momencie użytkownik w pełni replikuje środowisko węzłów i miejmy nadzieję, że wie, co robi i próbuje spełnić wymagania stylu węzła. Jeśli kod jest wywoływany w tagu skryptu, nadal będzie zabezpieczony przed nowymi zewnętrznymi zamknięciami.

Poniższe działa w przeglądarce, chyba że celowo, jawnie sabotowane:

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

Bam.

Oto całkiem fajny sposób, aby to zrobić:

const isBrowser = this.window === this;

To działa, ponieważ w przeglądarkach globalna zmienna „this” ma odniesienie do siebie zwane „window”. To odniesienie do siebie nie istnieje w Node.

• W przeglądarce „to” jest odniesieniem do obiektu globalnego, zwanego „oknem”.
• W węźle „this” jest odniesieniem do obiektu module.exports.
  • „this” nie jest odniesieniem do globalnego obiektu Node, zwanego „global”.
  • „this” nie jest odniesieniem do przestrzeni deklaracji zmiennej modułu.

Aby złamać powyższe sugerowane sprawdzenie przeglądarki, musisz wykonać coś podobnego do poniższego

this.window = this;

przed wykonaniem sprawdzenia.

Jeszcze jedno wykrycie środowiska :

(Znaczenie: większość odpowiedzi jest w porządku.)

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 ?..
}

Trochę paranoicznie, prawda? Możesz uczynić to bardziej szczegółowym, sprawdzając więcej elementów globalnych .

Ale NIE !.

Wszystko to i tak można sfałszować / zasymulować.

Na przykład, aby sfałszować globalobiekt:

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

Nie zostanie to dołączone do oryginalnego obiektu globalnego węzła, ale zostanie dołączone do windowobiektu w przeglądarce. Oznacza to, że jesteś w Node env w przeglądarce.

Życie jest krótkie!

Czy obchodzi nas, czy nasze środowisko jest fałszywe? Stałoby się tak, gdyby jakiś głupi programista zadeklarował zmienną globalną o nazwie globalw zasięgu globalnym. Albo jakiś zły programista w jakiś sposób wstrzykuje kod do naszego pliku env.

Możemy uniemożliwić wykonanie naszego kodu, gdy to złapiemy, ale może to spowodować wiele innych zależności naszej aplikacji. W końcu kod się zepsuje. Jeśli twój kod jest wystarczająco dobry, nie powinieneś przejmować się każdym głupim błędem, który mógł popełnić ktoś inny.

Więc co?

W przypadku kierowania na 2 środowiska: przeglądarka i węzeł;
"use strict"; i albo po prostu sprawdź windowlub global; i wyraźnie wskaż, że w dokumentach Twój kod obsługuje tylko te środowiska. Otóż ​​to!

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

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

Jeśli to możliwe dla twojego przypadku użycia; zamiast wykrywania środowiska; wykonuje synchroniczne wykrywanie funkcji w bloku try / catch. (ich wykonanie zajmie kilka milisekund).

na przykład

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

Większość proponowanych rozwiązań faktycznie można sfałszować. Solidnym sposobem jest sprawdzenie wewnętrznej Classwłaściwości obiektu globalnego przy użyciu rozszerzenia Object.prototype.toString. Klasy wewnętrznej nie można sfałszować w JavaScript:

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

Co na temat korzystania z obiektu procesu i sprawdzania execPath za node?

process.execPath

To jest bezwzględna ścieżka do pliku wykonywalnego, który rozpoczął proces.

Przykład:

/ usr / local / bin / node

W jaki sposób skrypt może stwierdzić, czy był wymagany jako moduł commonjs?

Powiązane: aby sprawdzić, czy był wymagany jako moduł, czy też działa bezpośrednio w węźle, możesz sprawdzić require.main !== module. http://nodejs.org/docs/latest/api/modules.html#accessing_the_main_module

Oto moja odmiana tego, co powyżej:

(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;});

Aby go użyć, zmodyfikuj "House" w drugim ostatnim wierszu tak, aby była dowolną nazwą modułu w przeglądarce i opublikuj jakąkolwiek chcesz wartość modułu (zwykle konstruktor lub literał obiektu ).

W przeglądarkach globalnym obiektem jest window i ma odniesienie do samego siebie (jest window.window, które jest == window). Wydaje mi się, że jest to mało prawdopodobne, chyba że jesteś w przeglądarce lub w środowisku, które chce, abyś uwierzył, że jesteś w przeglądarce. We wszystkich innych przypadkach, jeśli istnieje zadeklarowana globalna zmienna „moduł”, używa jej, w przeciwnym razie używa obiektu globalnego.

Używam processdo sprawdzenia node.js w ten sposób

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

lub

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

Udokumentowane tutaj

W chwili pisania tego artykułu ta odpowiedź jest raczej opcją „wkrótce”, ponieważ wykorzystuje bardzo nowe funkcje JavaScript.

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

runtimeWartość będzie albo nodealbo not node.

Jak wspomniano, zależy to od kilku nowych funkcji JavaScript. globalThisto sfinalizowana funkcja w specyfikacji ECMAScript 2020. Opcjonalne łączenie łańcuchowe / zerowe łączenie ( ?część globalThis.process?.release?.name) jest obsługiwane w silniku V8, który jest dostarczany z Chrome 80. Od 08.04.2020 ten kod będzie działał w przeglądarce, ale nie będzie działał w Node, ponieważ gałąź Node 13 używa V8 7.9.xxx. Uważam, że Node 14 (ma zostać wydany 21.04.2020) ma używać V8 8.x +.

Takie podejście wiąże się ze sporą dawką obecnych ograniczeń. Jednak; tempo, w jakim publikowane są przeglądarki / węzeł, ostatecznie będzie niezawodnym, jednolinijkowym.

Node.js ma processobiekt, więc jeśli nie masz żadnego innego skryptu, który go tworzy, processmożesz go użyć do określenia, czy kod działa w 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");
}

Jest to całkiem bezpieczny i prosty sposób na zapewnienie kompatybilności między javascriptem po stronie serwera i klienta, który będzie również działał z zawartymi po stronie klienta browserify, RequireJS lub CommonJS:

(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;
}())

Edycja : W odniesieniu do zaktualizowanego pytania: „W jaki sposób skrypt może stwierdzić, czy był wymagany jako moduł commonjs?” Myślę, że nie może. Możesz sprawdzić, czy exportsjest to obiekt ( if (typeof exports === "object")), ponieważ specyfikacja wymaga, aby była dostarczana do modułów, ale jedyne, co ci mówi, to to, że ... exportsjest obiektem. :-)

Oryginalna odpowiedź:

Jestem pewien, że istnieje jakiś symbol specyficzny dla NodeJS ( EventEmitterbyć może nie, musisz go użyć, requireaby pobrać moduł zdarzeń; patrz poniżej ), który możesz sprawdzić, ale jak powiedział David, najlepiej byłoby, gdybyś wykrył tę funkcję (raczej niż środowisko), jeśli ma to jakiś sens.

Aktualizacja : Może coś takiego:

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

Ale to tylko mówi ci, że jesteś w środowisku z requireczymś bardzo, bardzo podobnym do NodeJS Buffer. :-)

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

Ze źródła pakietu debugowania:

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

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

Weź źródło node.js i zmień je, aby zdefiniować zmienną, taką jak runningOnNodeJS. Sprawdź tę zmienną w swoim kodzie.

Jeśli nie możesz mieć własnej prywatnej wersji node.js, otwórz żądanie funkcji w projekcie. Poproś, aby zdefiniowali zmienną, która podaje wersję node.js, w której pracujesz. Następnie sprawdź tę zmienną.

Bardzo stary post, ale właśnie go rozwiązałem, opakowując wymagane instrukcje w próbkę

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