Comprendre les différents formats de modules javascript

BY admin
|

Lorsqu’il s’agit de construire votre application, si vous êtes comme moi vous vous demandez toujours : quel format dois-je utiliser ? CJS ? AMD ? UMD ? ESM ? Quelles sont les différences ? Pourquoi tant de formats ?

A travers cet article, je vais essayer de répondre à ces questions 😊.

#Les différents formats

#CommonJS (CJS)

C’est l’un des premiers formats créés. Je suis presque sûr que vous l’avez déjà utilisé. C’est le système de modules qui a initialement inspiré NodeJS.

Ce système repose sur l’importation et l’exportation de modules grâce à des mots-clés bien connus : require et exports. L’objet module.exports est vraiment spécifique à NodeJS.

 // utils.js // we create a function function add(r){ return r + r; } // export (expose) add to other modules exports.add = add; // index.js var utils = require('./utils.js'); utils.add(4); // = 8

L’équipe de commonJS a créé cette API comme une API synchrone qui n’est pas si bonne pour les navigateurs…. De plus, Commonjs n’est pas compris nativement par les navigateurs, il faut soit une bibliothèque de chargement, soit une certaine transpilation.

Définition de module asynchrone (AMD)

AMD est une sorte de scission de CommonJS. Il a été créé par des membres de l’équipe CJS qui n’étaient pas d’accord avec la direction prise par le reste de l’équipe.

Ils ont décidé de créer AMD pour supporter le chargement asynchrone des modules. C’est le système de modules utilisé par RequireJS et qui fonctionne côté client (dans les navigateurs).

 // add.js define(function() { return add = function(r) { return r + r; } }); // index.js define(function(require) { require('./add'); add(4); // = 8 }

Cet exemple ne fonctionne que si vous avez requirejs sur votre site web. Vous pouvez trouver d’autres exemples AMD.

#Universal Module Definition (UMD)

Comme vous l’avez compris ces 2 formats sont malheureusement mutuellement inintelligibles l’un pour l’autre. C’est pourquoi l’UMD a été créé. Il est basé sur l’UMD mais avec quelques cas particuliers inclus pour gérer la compatibilité CommonJS.

Malheureusement, cette compatibilité ajoute une certaine complexité qui rend la lecture / écriture compliquée. Si vous le souhaitez, vous pouvez trouver de multiples modèles de code UMD sur ce dépôt github.

Modules #ES2015 (ESM)

Comme ces 3 formats ne sont pas si faciles à lire, difficiles à analyser pour un analyseur de code statique et ne sont pas supportés partout, l’équipe de l’ECMA (l’équipe derrière la standardisation de Javascript) a décidé de créer le standard ECMAScript 2015 (aussi connu sous le nom d’ES6).Ce format est vraiment simple à lire et à écrire et supporte les modes de fonctionnement synchrones et asynchrones.

 // add.js export function add(r) { return r + r; } // index.js import add from "./add"; add(4); // = 8

De plus, les modules es peuvent être analysés statiquement ce qui permet aux outils de build (comme Webpack ou Rollup) d’effectuer du tree-shaking sur le code. Tree-shaking est un processus qui supprime le code inutilisé des bundles.

Malheureusement, ce format a encore 2 inconvénients (mais ils s’améliorent):

  • ESM ne supporte pas les modules importés dynamiquement mais il y a une proposition depuis des mois qui a commencé à être mise en œuvre sur certains navigateurs.
  • Ce n’est pas supporté sur tous les navigateurs mais heureusement, cela peut être « corrigé » grâce au… transpiling !

#Transpiling

Le transpiling est le processus de traduction d’une langue ou d’une version d’une langue vers une autre. Donc ici, l’idée est de transpiler ES6 vers ES5 pour obtenir un meilleur support des navigateurs.Malheureusement, cette transpilation a un coût car elle ajoute du code supplémentaire pour patcher les fonctionnalités manquantes de ES6 qui n’existent pas dans ES5.

Le transpilateur le plus célèbre qui est habituellement utilisé dans ce cas est Babel.

#Lectures complémentaires

Si vous voulez aller plus loin (à travers des exemples, des explications, etc.) pour comprendre comment fonctionnent ces différents formats, voici quelques lectures que j’ai trouvées et qui m’ont inspiré :

  • JavaScript Module Systems Showdown : CommonJS vs AMD vs ES2015
  • Vous devriez utiliser esm
  • Écrire du JavaScript modulaire avec AMD, CommonJS & ES Harmony
  • Qu’est-ce que AMD, CommonJS et UMD ?
  • Techniques de modularisation (il y a plusieurs pages ici)
  • L’état des modules JavaScript

.