2. Les types de modules JavaScript

Précédemment, nous avons vu qu’il y avait deux catégories de modules : les modules JavaScript, et les modules Node.js. Pour ne pas se perdre dans des explications trop farfelues, nous allons aborder en premier lieu les modules JavaScript.

Pour la petite histoire, JavaScript est un langage quasiment aussi âgé que le Web lui-même, et de l’eau à couler sous les ponts depuis.

Les développeurs de cette époque ont eus rapidement un problème de taille pour leurs applications JavaScript. Il a donc fallu répartir ces applications en plusieurs fichiers JavaScript distincts, afin de mieux organiser le code.

Cependant… il n’y a avait aucun concept de modules en JavaScript à ce moment-là Les modules ne font pas du tout partie de JavaScript à l’origine ! Il a donc fallu trouver un moyen de transformer tous ses fichiers JavaScript en un système de modules, plus ou moins fiable. L’objectif était de pouvoir partager des fonctionnalités, et réutiliser ces modules entre eux. Par exemple, utiliser une fonctionnalité exposée par le module A dans le module B. Bref, il fallait définir un format standard pour les modules JavaScript.

Du coup, tout le monde a mis la main à la patte, et un nombre important de formats de modules ont émergés dans le monde JavaScript. La plupart d’entre eux on soit disparus, ou alors sont quasiment inutilisés. Mais heureusement, quelques-uns sont parvenus jusqu’à nous :

  • Le format AMD, ou Asynchronous Module Definition, était utilisé dans les navigateurs, et se basait sur une fonction define pour définir les modules. Ce format est de moins en moins courant, et devrait disparaître prochainement.
  • Le format ES Module est un nouveau standard d’ECMAScript 6. Il apporte les mots-clefs export et import, et est utilisable directement dans les navigateurs les plus récents.
  • Le format CommonJS est le format standard pour les applications NodeJS ! Il utilise les mots-clefs require et module.exports, et l’éco-système NPM est en grande partie basé sur ce format actuellement. C’est donc naturellement ce format qui va nous intéresser par la suite.
  • Le format Universal Module Definition (UMD) est utile quand un module A a besoin d’être importé par différents autres modules B et C, qui eux-mêmes ne sont pas dans le même format. Encore un cas bizarroïde qui ne va pas tant nous intéresser que ça pour la suite.
  • Et un tas d’autres format de modules ! Comme je vous le disais, il y en a eu un paquet depuis l’apparition de JavaScript, mais beaucoup ont mal vieillis, et ont finis par disparaître.

Mais du coup… comment je m’y retrouve dans cette jungle ?  😳

Eh bien, pour le moment, c’est le format CommonJS qui est le standard utilisé dans les applications Node.js. C’est celui que vous retrouverez le plus souvent dans les extraits de code et les forums d’entraide que vous trouverez sur Internet.

Et c’est donc bien normal que ce soit ce standard que l’on va utiliser pour développer les modules JavaScript qui vont constituer notre API Rest Node.js.

Et rassurez-vous, si toutes ces explications vous font mal à la tête, prenez ça comme un bon signe. Ce sont les bases robustes de JavaScript qui rentre !

Des efforts sont faits en ce moment pour supporter directement le format ES Module dans Node.js, à partir de la version 13. Mais pour le moment, la majorité du code Node.js que vous rencontrerez utilise encore le format CommonJS.

Dans le format CommonJS, les modules sont chargés de manière synchrone, dans l’ordre dans lequel ils sont rencontré par le compilateur JavaScript utilisé. Cette approche a été conçu avec l’idée d’utiliser JavaScript côté serveur, c’est pour cela que vous ne trouverez jamais des modules CommonJS côté frontend, comme dans une application web par exemple.