Comment vérifier si un script s'exécute sous Node.js?

159

J'ai un script que je demande à un script Node.js, que je souhaite garder indépendant du moteur JavaScript.

Par exemple, je veux le faire exports.x = y;uniquement s'il fonctionne sous Node.js. Comment puis-je effectuer ce test?


En posant cette question, je ne savais pas que la fonctionnalité des modules Node.js était basée sur CommonJS .

Pour l'exemple spécifique que j'ai donné, une question plus précise aurait été:

Comment un script peut-il savoir s'il a été requis en tant que module CommonJS?

theosp
la source
3
Je ne sais pas pourquoi vous essayez de faire cela, mais en règle générale, vous devriez utiliser la détection des fonctionnalités plutôt que la détection du moteur. quirksmode.org/js/support.html
Quentin
4
Il s'agit en fait d'une demande sur la façon d'implémenter la détection des fonctionnalités, mais la question se décrit mal.
monokrome
publié une bibliothèque pour mon propre usage, aidez-moi cela aidera npmjs.com/package/detect-is-node
abhirathore2006
Un problème avec la question, et la plupart des réponses, est l'hypothèse qu'il n'y a que deux possibilités: Browser ou Node.js. Il est possible que ce ne soit ni navigateur ni Node.js, comme dans le cas d'Oracle Java Nashorn. Si le JDK est installé, la commande jjs vous permet d'exécuter des scripts. Mais il existe de nombreuses différences entre Nashorn et Node.js, vous ne pouvez donc faire aucune hypothèse. Et qui sait quelles options l'avenir peut offrir? Une détection des fonctionnalités est nécessaire.

Réponses:

80

En recherchant le support CommonJS , voici comment la bibliothèque Underscore.js le fait:

Modifier: à votre question mise à jour:

(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'exemple ici conserve le modèle de module.

Ross
la source
45
Cela détecte la prise en charge de CommonJS, que les navigateurs peuvent prendre en charge.
mikemaccana
7
Il y a un problème ici et le cloueur "l'a cloué". J'essaie CommonJS dans le navigateur et le chargeur de module que j'utilise définit module.exports, donc cette solution me dirait à tort que je suis dans le nœud.
Mark Melville
1
@MarkMelville sans doute, c'est exactement ce que l'OP demande donc donc pas de problème .
Ross
13
Mauvaise formulation de ma part. Je veux dire qu'il y a un problème avec cette solution. Le PO l'a peut-être accepté, mais moi non.
Mark Melville
7
Ce n'est certainement PAS la meilleure réponse donnée.
user3751385
107

Eh bien, il n'y a pas de moyen fiable de détecter l'exécution dans Node.js puisque chaque site Web peut facilement déclarer les mêmes variables, mais comme il n'y a pas d' windowobjet dans Node.js par défaut, vous pouvez aller dans l'autre sens et vérifier si vous exécutez dans un Navigateur.

C'est ce que j'utilise pour les bibliothèques qui devraient fonctionner à la fois dans un navigateur et sous Node.js:

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

} else {
    window.foo = {};
}

Cela peut encore exploser au cas où cela windowest défini dans Node.js, mais il n'y a aucune bonne raison pour que quelqu'un fasse cela, car vous auriez explicitement besoin d'omettre varou de définir la propriété sur l' globalobjet.

ÉDITER

Pour détecter si votre script a été requis en tant que module CommonJS, ce n'est encore une fois pas facile. La seule chose que commonJS spécifie est que A: Les modules seront inclus via un appel à la fonction requireet B: Les modules exportent des choses via des propriétés sur l' exportsobjet. Maintenant, comment cela est mis en œuvre est laissé au système sous-jacent. Node.js enveloppe le contenu du module dans une fonction anonyme:

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

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

Mais n'essayez pas de détecter cela via des arguments.callee.toString()choses folles , utilisez simplement mon exemple de code ci-dessus qui vérifie le navigateur. Node.js est un environnement plus propre, il est donc peu probable qu'il windowy soit déclaré.

Ivo Wetzel
la source
2
À propos de "Node.js est un environnement plus propre, il est donc peu probable que la fenêtre y soit déclarée.": Eh bien, je viens de chercher un moyen de savoir si mon script s'exécutait dans un navigateur émulé par node.js + JSDOM ou dans un navigateur simple ... La raison est que j'ai une boucle infinie utilisant setTimeout pour vérifier l'emplacement de l'URL, ce qui est bien dans un navigateur, mais maintient le script node.js en cours d'exécution pour toujours ... Il pourrait donc y avoir une fenêtre dans un script node.js après tout :)
Eric Bréchemier
1
@Eric Je doute fortement que ce soit là dans la portée globale, donc à moins que vous importiez quelque chose comme windowdans la première ligne de votre module, vous ne devriez pas avoir de problèmes. Vous pouvez également exécuter une fonction anonyme et vérifiez la [[Class]]de l' thisintérieur (fonctionne uniquement en mode non-stricte) Voir « Classe » sous: bonsaiden.github.com/JavaScript-Garden/#typeof
Ivo Wetzel
1
Mon problème diffère légèrement des OP: je n'ai pas besoin du script, il est chargé par JSDOM avec la fenêtre émulée comme contexte global ... Il est toujours exécuté par node.js + V8, juste dans un contexte différent des modules habituels.
Eric Bréchemier
1
Probablement ... je suis allé dans une autre direction: 1) détecter le support pour onhashchange ("onhashchange" dans la fenêtre) pour éviter de créer la boucle infinie 2) simuler le support en définissant la propriété onhashchange sur la fenêtre émulée dans le script principal node.js.
Eric Bréchemier le
1
typeof self === 'object'pourrait être plus sûr car typeof window === 'undefined'échoue sur la portée des travailleurs Web.
Lewis
45

Je suis actuellement tombé sur une mauvaise détection de Node qui n'est pas conscient de l'environnement Node dans Electron en raison d'une détection de fonction trompeuse. Les solutions suivantes identifient explicitement l'environnement de processus.


Identifier Node.js uniquement

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

Cela permettra de découvrir si vous exécutez dans un processus Node, car process.releasecontient les "métadonnées liées à la version actuelle de [Node-]".

Après l' apparition de io.js, la valeur de process.release.namepeut également devenir io.js(voir le processus-doc ). Pour détecter correctement un environnement prêt pour les nœuds, je suppose que vous devez vérifier ce qui suit:

Identifier le nœud (> = 3.0.0) ou io.js

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

Cette déclaration a été testée avec Node 5.5.0, Electron 0.36.9 (avec Node 5.1.1) et Chrome 48.0.2564.116.

Identifier le nœud (> = 0.10.0) ou io.js

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

Le commentaire de @ daluege m'a inspiré à réfléchir à une preuve plus générale. Cela devrait fonctionner à partir de Node.js> = 0,10 . Je n'ai pas trouvé d'identifiant unique pour les versions précédentes.


Ps: Je poste cette réponse ici puisque la question m'amène ici, bien que l'OP recherchait une réponse à une question différente.

Florian Breisch
la source
2
Cela semble être de loin l'approche la plus fiable, merci. Bien que ne fonctionnant que pour la version> = 3.0.0.
filip
@daluege - merci pour l'inspiration. Je n'ai malheureusement pas trouvé de preuve inférieure à 0,10.
Florian Breisch
3
J'ai trouvé en utilisant react webpack processet process.versionexiste dans le bundle, j'ai donc ajouté une vérification supplémentaire pour savoir process.versionprocess.release.noden'est pas défini du côté client mais a une version de nœud comme valeur côté serveur
Aaron
@Aaron: merci pour cet indice. Je n'ai trouvé aucune définition de la process.versionvariable (dans react, webpack ou react-webpack). J'apprécierais tout indice où la variable de version est définie pour l'ajouter à la réponse. En fonction des contraintes de release.node au nœud> = 3.xx
Florian Breisch
2
One-liner et plus sûr:function isNodejs() { return typeof "process" !== "undefined" && process && process.versions && process.versions.node; }
brillout
25

Le problème lorsque vous essayez de déterminer dans quel environnement votre code s'exécute est que tout objet peut être modifié et déclaré, ce qui rend presque impossible de déterminer quels objets sont natifs de l'environnement et lesquels ont été modifiés par le programme.

Cependant, il existe quelques astuces que nous pouvons utiliser pour déterminer avec certitude dans quel environnement vous vous trouvez.

Commençons par la solution généralement acceptée utilisée dans la bibliothèque de soulignement:

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

Cette technique est en fait parfaitement adaptée pour le côté serveur, car lorsque la requirefonction est appelée, elle réinitialise l' thisobjet à un objet vide et redéfinit modulepour vous à nouveau, ce qui signifie que vous n'avez pas à vous soucier de toute falsification extérieure. Tant que votre code est chargé avec require, vous êtes en sécurité.

Cependant, cela s'effondre sur le navigateur, car tout le monde peut facilement définir modulepour donner l'impression que c'est l'objet que vous recherchez. D'une part, cela peut être le comportement que vous souhaitez, mais cela détermine également les variables que l'utilisateur de la bibliothèque peut utiliser dans la portée globale. Peut-être que quelqu'un veut utiliser une variable avec le nom modulequi s'y trouve exportspour une autre utilisation. C'est peu probable, mais qui sommes-nous pour juger des variables que quelqu'un d'autre peut utiliser, simplement parce qu'un autre environnement utilise ce nom de variable?

L'astuce cependant, c'est que si nous supposons que votre script est en cours de chargement dans la portée globale (ce qu'il sera s'il est chargé via une balise de script), une variable ne peut pas être réservée dans une fermeture externe, car le navigateur ne le permet pas . Souvenez-vous maintenant que dans node, l' thisobjet est un objet vide, pourtant, la modulevariable est toujours disponible. C'est parce qu'il est déclaré dans une fermeture externe. Nous pouvons donc corriger la vérification du soulignement en ajoutant une vérification supplémentaire:

this.module !== module

Avec cela, si quelqu'un déclare moduledans la portée globale dans le navigateur, il sera placé dans l' thisobjet, ce qui entraînera l'échec du test, car ce this.modulesera le même objet que le module. Sur le nœud, this.modulen'existe pas et moduleexiste dans une fermeture externe, donc le test réussira, car ils ne sont pas équivalents.

Ainsi, le test final est:

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

Remarque: Bien que cela permette maintenant à la modulevariable d'être utilisée librement dans la portée globale, il est toujours possible de contourner cela sur le navigateur en créant une nouvelle fermeture et en déclarant à l' moduleintérieur, puis en chargeant le script dans cette fermeture. À ce stade, l'utilisateur réplique entièrement l'environnement de nœud et, espérons-le, sait ce qu'il fait et essaie de faire un style de nœud requis. Si le code est appelé dans une balise de script, il sera toujours à l'abri de toute nouvelle fermeture externe.

Temps
la source
2
Wow, merci d'avoir expliqué clairement la raison d'être de chaque pièce de votre one-liner.
Jon Coombs
obtenu Cannot read property 'module' of undefinedparce que cela n'est pas défini dans les tests moka par exemple
srghma
20

Les éléments suivants fonctionnent dans le navigateur à moins d'être sabotés intentionnellement et explicitement:

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

Bam.

user3751385
la source
4
var process = {toString: function () {return '[processus objet]'; }};
Nick Desaulniers
1
Y a-t-il une raison pour laquelle vous utilisez à la process+''place de process.toString()?
Harmic
3
Presque. Utilisez ceci à la place:Object.prototype.toString.call(process)
sospedra
2
C'est la meilleure réponse à cette question.
loretoparisi
3
@harmic: var process = null;ferait échouer le deuxième cas. En Javascript et en Java, l'expression '' + xproduit la même chose que x.toString()sauf quand xest méchant, le premier produit "null"ou "undefined"lorsque le second lèverait une erreur.
joeytwiddle
17

Voici une façon assez cool de le faire aussi:

const isBrowser = this.window === this;

Cela fonctionne parce que dans les navigateurs, la variable globale «this» a une auto-référence appelée «fenêtre». Cette auto-référence n'existe pas dans Node.

  • Dans le navigateur, «ceci» est une référence à l'objet global, appelé «fenêtre».
  • Dans Node 'this' est une référence à l'objet module.exports.
    • 'this' n'est pas une référence à l'objet global Node, appelé 'global'.
    • 'this' n'est pas une référence à l'espace de déclaration des variables du module.

Pour briser la vérification du navigateur suggérée ci-dessus, vous devez faire quelque chose comme ce qui suit

this.window = this;

avant d'exécuter la vérification.

Patrick
la source
Pourquoi pas simplement const isBrowser = this.window !== undefined? Et en théorie, dans le nœud, je peux faire this.window = thispour tromper la solution.
Tyler Long
11

Encore une autre détection d'environnement :

(Ce qui signifie: la plupart des réponses ici sont correctes.)

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 peu paranoïaque non? Vous pouvez rendre cela plus détaillé en recherchant plus de globaux .

Mais NE PAS!.

Tout ce qui précède peut être truqué / simulé de toute façon.

Par exemple pour simuler l' globalobjet:

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

Cela ne sera pas attaché à l'objet global d'origine du nœud mais il sera attaché à l' windowobjet dans un navigateur. Cela impliquera donc que vous êtes dans Node env dans un navigateur.

La vie est courte!

Est-ce que nous nous soucions si notre environnement est truqué? Cela arriverait quand un développeur stupide déclarait une variable globale appelée globaldans la portée globale. Ou un développeur maléfique injecte du code dans notre env.

Nous pouvons empêcher notre code de s'exécuter lorsque nous détectons cela, mais de nombreuses autres dépendances de notre application pourraient être prises en compte. Donc, finalement, le code se cassera. Si votre code est assez bon, vous ne devriez pas vous soucier de chaque erreur stupide qui aurait pu être commise par d'autres.

Et alors?

Si vous ciblez 2 environnements: navigateur et nœud;
"use strict"; et vérifiez simplement windowou global; et indiquez clairement que dans la documentation que votre code ne prend en charge que ces environnements. C'est tout!

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

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

Si possible pour votre cas d'utilisation; au lieu de la détection d'environnement; faire une détection de fonction synchrone dans un bloc try / catch. (ceux-ci prendront quelques millisecondes pour s'exécuter).

par exemple

function isPromiseSupported() {
    var supported = false;
    try {
        var p = new Promise(function (res, rej) {});
        supported = true;
    } catch (e) {}
    return supported;
}
Onur Yıldırım
la source
9

La plupart des solutions proposées peuvent en fait être truquées. Une méthode robuste consiste à vérifier la Classpropriété interne de l'objet global à l'aide du Object.prototype.toString. La classe interne ne peut pas être falsifiée en JavaScript:

var isNode = 
    typeof global !== "undefined" && 
    {}.toString.call(global) == '[object global]';
Fabian Jakobs
la source
2
Cela reviendra vrai sous browserify.
alt
1
Avez-vous testé cela? Je ne vois pas comment browserify peut changer la classe interne d'un objet. Cela nécessiterait de changer le code dans la machine virtuelle JavaScript ou d'écraser, Object.prototype.toStringce qui est vraiment une mauvaise pratique.
Fabian Jakobs
Je l'ai testé. Voici ce que fait browserify: var global=typeof self !== "undefined" ? self : typeof window !== "undefined" ? window : {};
Vanuan
Vous voyez, dans Chrome, ({}.toString.call(window))c'est égal "[object global]".
Vanuan
2
C'est étrange, car window.toString()produit"[object Window]"
Vanuan
5

Qu'en est- il d' utiliser l'objet de processus et de contrôle execPath pour node?

process.execPath

C'est le chemin absolu de l'exécutable qui a démarré le processus.

Exemple:

/ usr / local / bin / node

Kevin Hakanson
la source
2
Et quoi window.process = {execPath: "/usr/local/bin/node"};?
Константин Ван
4

Voici ma variation sur ce qui précède:

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

Pour l'utiliser, vous modifiez la "Maison" sur l'avant-dernière ligne pour qu'elle soit ce que vous voulez que le nom du module soit dans le navigateur et publiez ce que vous voulez que la valeur du module soit (généralement un constructeur ou un objet littéral ).

Dans les navigateurs, l'objet global est window, et il a une référence à lui-même (il y a un window.window qui est == window). Il me semble que cela ne se produira probablement pas à moins que vous ne soyez dans un navigateur ou dans un environnement qui veut que vous croyiez que vous êtes dans un navigateur. Dans tous les autres cas, s'il y a une variable globale 'module' déclarée, il l'utilise sinon il utilise l'objet global.

kybernetikos
la source
4

J'utilise processpour vérifier node.js comme ça

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

ou

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

Documenté ici

Chris
la source
2
process.titlepeut être changé
Ben Barkay
Vérifiez ensuite le titre dans lequel vous l'avez changé. Ou utilisez process.version
Chris
Si vous écrivez pour une bibliothèque (comme vous devriez), vous ne pourrez pas vous attendre à ce que le titre devrait être
Ben Barkay
3

Au moment d'écrire ces lignes, cette réponse est plus une option "à venir", car elle exploite de très nouvelles fonctionnalités de JavaScript.

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

La runtimevaleur sera soit nodeou not node.

Comme mentionné, cela repose sur quelques nouvelles fonctionnalités JavaScript. globalThisest une fonctionnalité finalisée dans la spécification ECMAScript 2020. Le chaînage facultatif / la fusion nulle (la ?partie de globalThis.process?.release?.name) est pris en charge dans le moteur V8, qui est livré avec Chrome 80. À partir du 8/04/2020, ce code fonctionnera dans le navigateur mais ne fonctionnera pas dans Node puisque la branche Node 13 utilise V8 7.9.xxx. Je crois que Node 14 (dont la sortie est prévue le 21/04/2020) est censé utiliser V8 8.x +.

Cette approche s'accompagne d'une bonne dose de restrictions actuelles. Toutefois; le rythme auquel les navigateurs / Node sont publiés, ce sera finalement un one-liner fiable.

Corey
la source
1
Cela devrait être la réponse acceptée! et tout le monde devrait utiliser le nœud 14 btw
Sceat
2

Node.js a un processobjet, donc tant que vous n'avez aucun autre script qui crée, processvous pouvez l'utiliser pour déterminer si le code s'exécute sur 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");
}
Dariusz Sikorski
la source
2

C'est un moyen assez sûr et simple d'assurer la compatibilité entre le javascript côté serveur et côté client, qui fonctionnera également avec browserify, RequireJS ou CommonJS inclus côté 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;
}())
Christophe Marois
la source
1

Edit : Concernant votre question mise à jour: "Comment un script peut-il dire s'il a été requis en tant que module commonjs?" Je ne pense pas que ce soit possible. Vous pouvez vérifier s'il exportss'agit d'un objet ( if (typeof exports === "object")), car la spécification exige qu'il soit fourni aux modules, mais tout ce qui vous dit est que ... exportsest un objet. :-)


Réponse originale:

Je suis sûr qu'il y a un symbole spécifique à NodeJS ( EventEmitterpeut-être que non, vous devez utiliser requirepour obtenir le module d'événements; voir ci-dessous ) que vous pourriez vérifier, mais comme David l'a dit, idéalement, vous feriez mieux de détecter la fonctionnalité (plutôt que l'environnement) si cela a du sens de le faire.

Mise à jour : Peut-être quelque chose comme:

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

Mais cela vous indique simplement que vous êtes dans un environnement avec requireet quelque chose de très, très similaire à celui de NodeJS Buffer. :-)

TJ Crowder
la source
Je peux toujours casser cela en installant tout cela dans un site Web ... c'est juste exagéré;) Vérifier si vous êtes dans un navigateur est plus facile car l'environnement Node est plus propre.
Ivo Wetzel
1
@Ivo: Oui, voyez ma dernière phrase. Je peux tout aussi facilement casser votre chèque en définissant une windowvariable dans une application NodeJS. :-)
TJ Crowder
1
@Ivo: Je ne serais pas du tout surpris si quelqu'un défini windowdans un module NodeJS, afin qu'il puisse inclure du code qui reposait sur le fait d' windowêtre l'objet global et ne voulait pas modifier ce code. Je ne le ferais pas, tu ne le ferais pas, mais je parie que quelqu'un l'a fait. :-) Ou ils ont juste utilisé windowpour signifier autre chose.
TJ Crowder
1
@Ivo: yuiblog.com/blog/2010/04/09/… est l'une des raisons pour lesquelles l'objet window peut être défini dans node.js
slebetman
1
@TJCrowdertypeof process !== "undefined" && process.title === "node"
Raynos
0
const isNode =
  typeof process !== 'undefined' &&
  process.versions != null &&
  process.versions.node != null;
BAR
la source
-1

Prenez la source de node.js et modifiez-la pour définir une variable comme runningOnNodeJS. Vérifiez cette variable dans votre code.

Si vous ne pouvez pas avoir votre propre version privée de node.js, ouvrez une demande de fonctionnalité dans le projet. Demandez-leur de définir une variable qui vous donne la version de node.js que vous utilisez. Ensuite, vérifiez cette variable.

Aaron Digulla
la source
1
Encore une fois, cela ne résout pas son problème (fondamentalement insoluble), je peux à nouveau créer une telle variable dans le navigateur. Le meilleur moyen serait d'empêcher les scripts de créer un windowglobal, je suppose que je vais déposer une demande de fonctionnalité sur celui-ci.
Ivo Wetzel
@Ivo: C'est une mauvaise idée qui briserait le code qui utilise jsdom ( github.com/tmpvar/jsdom ) pour faire une manipulation dom côté serveur en utilisant des bibliothèques familières comme YUI et jQuery. Et il y a du code actuellement en production qui fait cela.
slebetman
@slebetman Non, cela ne cassera pas jsdom. Je parle de global , comme dans no var statement global , l'exemple de code utilise l' varinstruction, des personnes qui la fuient simplement dans l'espace de noms global, eh bien, ils ne comprennent pas le concept de modules autonomes alors
Ivo Wetzel
@Ivo c'est un peu violent, c'est comme dire qu'on devrait prendre la capacité de manger des gâteaux parce que les gens grossissent en les mangeant trop. Vous devez encombrer l'espace de noms global pour obtenir une bibliothèque qui fonctionnera inter-module. Ou vous pouvez tout résumer dans un seul module, mais à quoi ça sert?
Ben Barkay
-1

Très ancien message, mais je viens de le résoudre en enveloppant les instructions require dans un try - catch

try {
     var fs = require('fs')
} catch(e) {
     alert('you are not in node !!!')
}
Stef de Vries
la source
2
Ce n'est pas vrai, vous pouvez utiliser browserify pour utiliser les appels "nodeish" require ()
fat