Question Relation entre CommonJS, AMD et RequireJS?


Je suis toujours très confus au sujet de CommonJS, AMD et RequireJS. Même après avoir beaucoup lu.

Je sais que CommonJS (anciennement ServerJS) est un groupe pour définir certaines spécifications JavaScript (c'est-à-dire des modules) lorsque la langue est utilisée en dehors du navigateur. La spécification des modules CommonJS a une implémentation comme Node.js ou RingoJS, n'est-ce pas?

Quelle est la relation entre CommonJS, la définition de module asynchrone (AMD) et RequireJS? Est-ce que RequireJS est une implémentation de la définition de module CommonJS? Si oui, qu'est-ce que AMD alors?


724
2018-05-13 11:56


origine


Réponses:


ExigerJS met en œuvre le AMD API (la source).

CommonJS est un moyen de définir des modules à l'aide d'un exports objet, qui définit le contenu du module. En termes simples, une implémentation CommonJS pourrait fonctionner comme ceci:

// someModule.js
exports.doSomething = function() { return "foo"; };

//otherModule.js
var someModule = require('someModule'); // in the vein of node    
exports.doSomethingElse = function() { return someModule.doSomething() + "bar"; };

Fondamentalement, CommonJS précise que vous devez avoir un require() fonction pour récupérer les dépendances, un exports variable pour exporter le contenu du module et un identificateur de module (qui décrit l'emplacement du module en question par rapport à ce module) qui est utilisé pour exiger les dépendances (la source). CommonJS a diverses implémentations, y compris Node.js, que vous avez mentionné.

CommonJS n'a pas été spécialement conçu pour les navigateurs, il ne s'intègre donc pas très bien dans l'environnement du navigateur (Je n'ai vraiment aucune source pour ça - ça le dit juste partout, y compris le site RequireJS.


688
2018-05-13 13:14



CommonJS est plus que cela - c'est un projet pour définir une API commune et un écosystème pour JavaScript. Une partie de CommonJS est la Module spécification. Node.js et RingoJS sont des runtimes JavaScript côté serveur, et oui, tous deux implémentent des modules basés sur la spécification CommonJS Module.

AMD (Asynchronous Module Definition) est une autre spécification pour les modules. ExigerJS est probablement l'implémentation la plus populaire d'AMD. Une différence majeure par rapport à CommonJS est que AMD spécifie que les modules sont chargés asynchrone - Cela signifie que les modules sont chargés en parallèle, au lieu de bloquer l'exécution en attendant la fin d'une charge.

AMD est généralement plus utilisé dans le développement JavaScript côté client (dans le navigateur) à cause de cela, et les modules CommonJS sont généralement utilisés côté serveur. Cependant, vous pouvez utiliser l'une ou l'autre des spécifications de module dans l'un ou l'autre des environnements - par exemple, les offres RequireJS directions pour courir dans Node.js et explorer est une implémentation de module CommonJS qui peut s'exécuter dans le navigateur.


189
2018-05-13 13:06



La réponse courte serait:

CommonJS et AMD sont des spécifications (ou des formats) sur la façon dont les modules et leurs dépendances doivent être déclarés dans les applications javascript.

ExigerJS est une bibliothèque de chargeur de script compatible avec AMD, curljs étant un autre exemple.

CommonJS conforme:

Pris à partir de Le livre d'Addy Osmani.

// package/lib is a dependency we require
var lib = require( "package/lib" );

// behavior for our module
function foo(){
    lib.log( "hello world!" );
}

// export (expose) foo to other modules as foobar
exports.foobar = foo;

AMD conforme:

// package/lib is a dependency we require
define(["package/lib"], function (lib) {

    // behavior for our module
    function foo() {
        lib.log( "hello world!" );
    }

    // export (expose) foo to other modules as foobar
    return {
        foobar: foo
    }
});

Quelque part ailleurs, le module peut être utilisé avec:

require(["package/myModule"], function(myModule) {
    myModule.foobar();
});

Quelques antécédents:

Réellement, CommonJS est beaucoup plus qu'une déclaration API et seulement une partie traite de cela. AMD a commencé comme un projet de spécification pour le format de module sur la liste CommonJS, mais un consensus total n'a pas été atteint et le développement du format a été déplacé vers le groupe amdjs. Arguments autour de quel format est le meilleur que CommonJS tente de couvrir un ensemble plus large de préoccupations et qu'il est mieux adapté pour le développement côté serveur étant donné sa nature synchrone, et AMD est mieux adapté au développement côté client (navigateur) étant donné sa nature asynchrone. fait qu'il a ses racines dans la mise en œuvre de la déclaration de module de Dojo.

Sources:


173
2017-12-29 23:05



Citant

AMD:

  • Une première approche par navigateur
  • Opter pour un comportement asynchrone et une compatibilité descendante simplifiée
  • Il n'a aucun concept d'E / S de fichier.
  • Il supporte les objets, fonctions, constructeurs, chaînes, JSON et bien d'autres types de modules.

CommonJS:

  • Une approche serveur-première
  • En supposant un comportement synchrone
  • Couvrez un ensemble plus large de préoccupations telles que les E / S, le système de fichiers, les promesses et plus encore.
  • Prend en charge les modules déballés, il peut se sentir un peu plus proche de la ES.next/Harmony spécifications, vous libérant de l'emballage define () AMD impose.
  • Seuls les objets de support en tant que modules.

21
2017-07-29 10:36



Il est tout à fait normal d'organiser le programme JavaScript en plusieurs fichiers et d'appeler child-modules du main js module.

La chose est JavaScript ne fournit pas cela. Pas même aujourd'hui dans les dernières versions de navigateur de Chrome et FF.

Mais, y at-il un mot clé en JavaScript pour appeler un autre module JavaScript?

Cette question peut être un effondrement total du monde pour beaucoup parce que la réponse est Non.


En ES5 (sorti en 2009) JavaScript n'avait pas de mots-clés comme importer, comprendre, ou exiger.

ES6 sauve la journée (sortie en 2015) proposant la importer mot-clé ( https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Statements/import ), mais aucun navigateur ne l'implémente.

Si vous utilisez Babel 6.18.0 et transpilez avec l'option ES2015 seulement

import myDefault from "my-module";

tu auras require encore.

"use strict";
var _myModule = require("my-module");
var _myModule2 = _interopRequireDefault(_myModule);
function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }

Ceci est dû au fait require signifie que le module sera chargé à partir de Node.js. Node.js va gérer tout depuis la lecture du fichier au niveau du système jusqu'aux fonctions d'enveloppement dans le module.

Parce que dans JavaScript, les fonctions sont les seuls wrappers à représenter les modules.

Je suis très confus à propos de CommonJS et AMD?

CommonJS et AMD ne sont que deux techniques différentes pour surmonter le "défaut" JavaScript de charger des modules intelligents.


9
2017-10-30 23:50