modules es
ES Modules : la norme pour le JavaScript modulaire
Les ES Modules, également connus sous le nom d'ECMAScript Modules ou ES6 Modules, constituent la norme officielle pour diviser le code JavaScript en modules. C'est un système qui a été introduit en 2015 dans le cadre de la spécification ECMAScript 2015 (ES6) et qui, depuis lors, a progressivement été préféré aux approches antérieures comme CommonJS. Les ES Modules offrent un moyen d'organiser le code en morceaux réutilisables, où des fonctions, des variables, des classes et des types peuvent être exportés depuis un fichier et importés dans d'autres fichiers. Ce système est désormais largement pris en charge dans les navigateurs web modernes et les runtimes JavaScript, y compris Node.js.
Avant que les ES Modules n'existent, il n'y avait pas de manière native en JavaScript d'utiliser des modules. Aux débuts de JavaScript, lorsque le langage tournait exclusivement dans les navigateurs, le code pouvait être découpé en plusieurs fichiers via plusieurs balises <script> dans le HTML. Bien que cela fût techniquement possible, cette approche présentait un gros inconvénient : tous les scripts partageaient la même portée globale. Cela signifiait que les variables et les fonctions d'un script étaient accessibles à tous les autres scripts, ce qui entraînait des risques de conflits de noms, de mutations involontaires et de code difficile à maintenir. En outre, il n'y avait pas de manière claire de déclarer explicitement les dépendances entre fichiers. Le développement des modules était donc une étape nécessaire dans l'évolution de JavaScript comme langage de programmation pour des applications à grande échelle.
Les ES Modules ont introduit une syntaxe claire et déclarative pour importer et exporter des valeurs. Le cœur du système se compose de deux mots-clés : export et import. Avec export, vous pouvez rendre une variable, une fonction ou une classe disponible pour d'autres fichiers. Avec import, vous pouvez utiliser ces valeurs exportées dans un autre fichier. Il existe deux types d'exports : les named exports et les default exports. Les named exports permettent d'exporter plusieurs valeurs depuis un seul fichier, chacune avec son propre nom. Les default exports permettent de désigner une valeur comme export « primaire », ce qui est pratique lorsqu'un fichier contient principalement une seule entité, comme un composant React ou une classe.
Un exemple de named export se présente comme suit :
// math.js
export const pi = 3.14159;
export function berekenOmtrek(straal) {
return 2 * pi * straal;
}
Et l'importation correspondante dans un autre fichier :
// app.js
import { pi, berekenOmtrek } from './math.js';
console.log(berekenOmtrek(5));
Pour un default export :
// greeting.js
export default function() {
return "Hallo, wereld!";
}
// app.js
import groet from './greeting.js';
console.log(groet());
Cette syntaxe est désormais standard dans le développement JavaScript moderne. TypeScript, un sur-ensemble de JavaScript qui ajoute des types statiques, prend entièrement en charge les ES Modules. En TypeScript, on peut exporter non seulement des valeurs, mais aussi des déclarations liées aux types comme les type aliases, les interfaces, les enums et les namespaces. Ceux-ci peuvent être exportés avec la même syntaxe export que les déclarations JavaScript classiques. Cela permet de rendre les types réutilisables sur plusieurs fichiers, ce qui est essentiel pour construire des applications bien structurées et sûres au niveau des types.
Bien que les ES Modules soient la norme actuelle, ce n'était pas la première tentative d'apporter de la modularité en JavaScript. CommonJS, un système de modules devenu surtout populaire dans Node.js, utilisait une approche différente basée sur module.exports et require(). Dans CommonJS, un module est délimité par une fermeture de fonction (closures), et les exports sont ajoutés à un objet module.exports. L'importation se fait via require(), une fonction synchrone qui retourne directement la valeur exportée. Cette approche fonctionnait bien dans les environnements serveur, mais était moins adaptée aux navigateurs, où les temps de chargement asynchrones et les opérations réseau jouent un rôle plus important.
Le passage de CommonJS aux ES Modules a apporté son lot de défis, surtout autour de l'interopérabilité. Comme les ES Modules sont statiques (les imports et exports doivent être analysables statiquement au moment de la construction), tandis que CommonJS est dynamique (les imports peuvent être conditionnels), l'interopérabilité directe n'est pas triviale. Pourtant, le compilateur TypeScript et les bundlers modernes comme Webpack, Vite et esbuild ont développé des mécanismes pour faire fonctionner les deux systèmes côte à côte. Par exemple : lorsqu'un ES Module importe un module CommonJS, le bundler peut assigner l'export default du module CommonJS à l'import default dans les ES Modules, ou rendre toutes les valeurs exportées disponibles sous forme d'un objet namespace.
Dans Node.js, les ES Modules n'ont été pris en charge que plus tard, à partir de la version 12, avec l'introduction de l'extension de fichier .mjs ou la définition de "type": "module" dans package.json. Cela a permis d'utiliser la syntaxe des ES Modules dans un runtime qui était à l'origine construit autour de CommonJS. La coexistence des deux systèmes dans un même environnement exige toutefois une configuration soignée, surtout dans les projets qui contiennent à la fois du code serveur et du code client.
Lorsque vous travaillez avec des ES Modules dans des projets plus importants, il est important de tenir compte de la configuration du compilateur TypeScript. Un seul tsconfig.json ne peut décrire qu'un seul environnement, tant en ce qui concerne les globals disponibles que le comportement des modules. Dans les applications comportant plusieurs parties — comme le code serveur, le code DOM, les webworkers et le code de test — il est recommandé d'utiliser un tsconfig.json séparé par environnement, relié via des project references. Cela garantit des frontières claires et évite les conflits de configuration.
Les ES Modules sont également devenus essentiels dans des frameworks et bibliothèques comme React. Dans React, la structure de l'interface utilisateur est souvent construite à partir de composants réutilisables, qui sont logiquement répartis dans différents fichiers. En utilisant import et export, les développeurs peuvent définir des composants dans un fichier et les utiliser dans d'autres fichiers, ce qui rend le code plus facile à maintenir et à réutiliser. Bien que React lui-même n'introduise pas de modules, l'utilisation des ES Modules est la pratique standard dans presque tous les projets React modernes.
En résumé, les ES Modules sont la manière établie d'organiser le code JavaScript de façon modulaire. Ils offrent une syntaxe claire et statique pour gérer les dépendances, sont largement pris en charge tant dans les navigateurs que dans les runtimes, et constituent la base des pratiques de développement modernes en combinaison avec TypeScript, les bundlers et les frameworks. Bien que le passage depuis des systèmes plus anciens comme CommonJS ait apporté des défis, les ES Modules sont devenus la norme universelle pour le développement JavaScript modulaire. Le système favorise la réutilisabilité, des dépendances claires et un meilleur support des outils, ce qui est essentiel pour construire des applications évolutives et maintenables dans le monde actuel du développement web.