Que signifie module.exports et exports.methods dans NodeJS?

Question

En regardant de façon aléatoire un fichier source de l'express cadre pour NodeJS (lien), il y a deux lignes de code que je ne comprends pas (ces lignes de code sont typiques de presque tous les NodeJS fichiers).

/**
 * Expose `Router` constructor.
 */

exports = module.exports = Router;

et

/**
 * Expose HTTP methods.
 */

var methods = exports.methods = require('./methods');

Je comprends que la première pice de code permet les fonctions suivantes dans le fichier d'être exposées à l'application NodeJS, mais je ne comprends pas exactement comment cela fonctionne, ou ce que le code de la ligne... ce qui ne les exportations et le module.les exportations signifie réellement?

Je crois que le 2e morceau de code permet les fonctions dans le fichier pour accéder à des "méthodes", mais encore une fois, comment faut-il faire à présent.

En gros, ce sont ces mots magiques? module et les exportations.

Answer 1

Pour être plus précis:

module est la portée globale de la variable à l'intérieur d'un fichier.

Donc, si vous appelez require("foo") alors :

// foo.js
console.log(this === module); // true

Il s'agit de la même façon qu' window des actes dans le navigateur.

Il y a aussi un autre objet global appelés global qui vous permet d'écrire et de lire à partir de n'importe quel fichier que vous voulez, mais qui implique la mutation de portée globale et c'est le MAL

exports est une variable qui vit sur module.exports. C'est fondamentalement ce que vous avez à l'exportation lorsqu'un fichier est nécessaire.

// main.js
console.log(require("foo") === 42); // true

// foo.js
module.exports = 42;

Il y a un petit problème avec exports sur son propre. La portée globale du contexte et de l' module ne sont pas les mêmes. (Dans le navigateur de la portée mondiale du contexte et de l' window sont les mêmes).

// foo.js
var exports = {}; // creates a new local variable called exports, and conflicts with
// living on module.exports
exports = {}; // does the same as above
module.exports = {}; // just works because its the "correct" exports

// bar.js
exports.foo = 42; // this does not create a new exports variable so it just works

Lire plus sur les exportations

Answer 2

Pour développer sur Raynos de réponse...

l '"exportation" est en fait un alias pour le module.exportations - je recommande juste de ne pas l'utiliser. Vous pouvez exposer des méthodes et des propriétés d'un module de réglage sur le module.les exportations, comme suit:

//file 'module1.js'
module.exports.foo = function () { return 'bar' }
module.exports.baz = 5

Ensuite, vous obtenez l'accès à votre code:

var module1 = require('module1')
console.log(module1.foo())
console.log(module1.baz)

Vous pouvez également remplacer le module.les exportations entièrement de simplement offrir un objet unique à exiger:

//glorp.js
module.exports = function () {
  this.foo = function () { return 'bar' }
  this.baz = 5
}

Maintenant, vous avez une bonne prototype:

var g1 = new require('glorp')()
console.log(g1.foo())
console.log(g1.baz)

Il existe une multitude d'autres façons de jouer avec le module.les exportations et exigent. Rappelez-vous juste, require('foo') renvoie toujours la même instance, même si vous l'appeler plusieurs fois.

Answer 3

Vous pouvez trouver la meilleure réponse à node.js le code source. Si quelqu'un est à la demande de votre js module, votre script se transforme en une fonction de nœud comme suit (voir src/node.js).

// require function does this..
(function (exports, require, module, __filename, __dirname) {
    ... your javascript contents...
});

Les noeuds de l'enveloppe de votre script. Puis au-dessus de script sera exécuté comme suit:

//module.js
var args = [self.exports, require, self, filename, dirname];
return compiledWrapper.apply(self.exports, args);

Donc, dans votre script,

exports is just module.exports.

Dans votre script, vous pouvez ajouter quelque chose à cela, les exportations de l'objet (fonctions..). exiger la fonction sera de retour cet objet. C'est node.js s'module (système de commonJS spécification).

Mais attention à ne pas modifier le module.les exportations. Sinon, votre actuelle des exportations sera vide de sens.

Answer 4

le module est un objet qui représente ce que la fichier particulier aimerais exposer publiquement. Au lieu d'avoir quelque chose qui ressemble à des fichiers d'en-tête dans le c/c++ monde, vous décrire ce que le module exportations par la définition de cet objet. le nœud d'exécution puis utilise cet objet pour déterminer quel module est "publique".

ses un concept similaire à l'exportation de fonctions à partir d'une dll dans le compilé monde. vous devez définir explicitement ce que les fonctions peuvent être consultés par le monde extérieur. cela permet à l'encapsulation et vous permet d'organiser vos bibliothèques de façon propre.