Variables globales pour les modules standards node.js ?

Question

Je sais que les variables globales sont mauvaises.

Mais si j'utilise le module "util" de node dans 40 fichiers de mon framework, n'est-il pas préférable de le déclarer comme une variable globale comme :

util = require('util');

dans le fichier index.js au lieu d'écrire cette ligne dans 40 fichiers ?

Parce que j'utilise souvent les mêmes 5-10 modules dans chaque fichier, cela me ferait gagner beaucoup de temps au lieu de copier-coller tout le temps.

La méthode DRY n'est-elle pas bonne dans ce cas ?

Answer 1

Vous pourriez simplement avoir un module commun.

common.js :

Common = {
  util: require('util'),
  fs:   require('fs'),
  path: require('path')
};

module.exports = Common;

app.js :

var Common = require('./common.js');
console.log(Common.util.inspect(Common));

Answer 2

Chaque module est censé être indépendant. L'exigence ne coûte rien de toute façon après la première pour chaque module.

Et si vous vouliez tester un module seul ? Vous auriez beaucoup de problèmes parce qu'il ne reconnaîtrait pas certaines exigences "globales" que vous avez dans votre application.

Oui, les globaux sont mauvais, même dans ce cas. Les globaux ruinent presque toujours : la testabilité, l'encapsulation et la facilité de maintenance.

Réponse actualisée Jan. 2012

~~

El global est maintenant un objet global dans chaque module. Ainsi, chaque fois que vous assignez à une variable globale (sans portée) à l'intérieur d'un module, celle-ci devient une partie de l'objet de l'utilisateur. global de ce module.

~~

El global n'est donc toujours pas mondial et ne peut être utilisé en tant que tel.

Mis à jour en décembre 2012

El global a maintenant une portée globale dans l'application et peut être utilisé pour stocker toutes les données/fonctions qui doivent être accessibles à partir de tous les modules.

Answer 3

global.util = require('util');

Il y a une section sur les objets globaux dans le manuel de l'utilisateur. documentation des nœuds .

Cependant, les globaux doivent être utilisés avec précaution. En ajoutant des modules à l'espace global, vous réduisez la testabilité et l'encapsulation. Mais il existe des cas où l'utilisation de cette méthode est acceptable. Par exemple, j'ajoute des fonctions et des objets à l'espace de noms global pour les utiliser dans mes scripts de tests unitaires.

Answer 4

Je suis confus par les réponses dans ce fil.

Je suis capable de faire ça...

Fichier : test.js

global.mytest = {
    x: 3,
    y: function() { console.log('Works.'); }
};

Fichier : test2.js

console.log('Does this work?');
mytest.y();

Fichier : server.js

require('test.js');
require('test2.js');

Et cela semble fonctionner comme la question l'exigeait. Le premier require place l'objet mytest dans la portée globale, puis le second require peut accéder à cet objet sans aucun autre qualificatif.

J'essayais de résoudre ce problème (ce qui m'a amené à ce fil de discussion à partir d'une recherche Google) et je voulais poster ce qui semble fonctionner pour moi maintenant. Peut-être les choses ont-elles changé depuis les réponses initiales.

Answer 5

J'ai utilisé avec succès le process pour faire circuler mon objet de configuration. Bien qu'en théorie, il souffre des mêmes problèmes que ceux mentionnés ci-dessus (encapsulation, testabilité, etc.), il fonctionne bien lorsqu'il n'utilise que des propriétés non modifiables (une table de hachage avec des primitives, en gros).