Les modules ECMAScript 6, au delà de CommonJS et AMD

Dr. Axel Rauschmayer a annoncé la version finale de la syntaxe des modules ECMAScript 6 (ES6).

Dans son article "les modules ECMAScript 6 : la syntaxe finale", Rauschmayer présente une vue détaillée du système de modules ES6, qui inclut les modules ECMAScript 6, les metadata de modules, et l'API module loader.

Selon Rauschmayer, le but des modules ES6 est de créer un format avec lequel les utilisateurs de CommonJS et d'AMD sont familiers, et qu'en l'intégrant au langage, l'on puisse aller plus loin qu'AMD et CommonJS.

En ES6, il y a deux types d'exports. Les premiers sont les "exports nommés" (plusieurs par module), et les seconds sont les "exports par défaut" (un par module). Avec les exports nommés, un module peut exporter de multiples éléments en introduisant leurs déclarations avec le mot-clé export - et sont distingués par leurs noms.

Rauschmayer explique :

Il y a d'autres façons de définir des exports nommés, mais je trouve celle-là particulièrement pratique : écrivez simplement votre code comme s'il n'y avait pas de monde extérieur, puis mettez des labels sur tout ce que vous souhaitez exporter.

Si vous le souhaitez, vous pouvez également importer tout le module et accéder à ses exports nommés via les propriétés.

Les exports par défaut en ES6 sont les valeurs exportées les plus importantes, et Rauschmayer explique qu'ils sont particulièrement simple à importer. Il souligne aussi que les exports à une seule valeur sont courants en développement front end où l'on a souvent des constructeurs / classes avec un seul modèle par module.

ES6 propose une manière d'accéder à des informations sur le module courant (par exemple l'URL du module). Dans ce cas, le module est un jeton indiquant que les meta-données sont importées "en tant que module". Ainsi :

`import { url } from this module;

console.log(url);`

Les meta-données peuvent aussi être accédées via un objet :

`import * as metaData from this module;

console.log(metaData.url);`

En plus de la syntaxe déclarative des modules, ES6 possède aussi une API permettant aux développeurs de travailler avec les modules et les scripts, et de configurer le chargement des modules. Avec cette API, Rauschmayer explique :

Les Loaders gèrent les modules (les IDs à la fin de import...from), le chargement des modules, etc. Le constructeur est Reflect.Loader. Chaque plateforme conserve une instance personnalisée dans la variable globale System (le loader système), qui implémente son propre système de chargement de module.   Rauschmayer détaille aussi le fait que l'API loader possède plusieurs points d'attaches pour la configuration, qu'il décrit pour l'instant comme "en cours de construction" mais qui permettra à terme "de vraiment personnaliser le processus de chargement". Par exemple :

• Passer les modules au Lint à l'import (JSLint ou JSHint)
• Transpilation automatique des modules à l'import (s'ils contiennent du CoffeeScript ou du TypeScript)
• Utilisation des anciens modules (AMD, Node.js)

Selon Rauschmayer, le chargement configurable de modules est un domaine où Node.js et CommonJS sont limités.

Les réactions de la communauté à cette version finale ont été largement positives.

Sur Reddit, dans la discussion les modules ECMAScript 6 : la syntaxe finale (en), l'utilisateur brtt3000 commente: "J'aime cette version qui a l'air de couvrir toutes les parties importantes, et la syntaxe est vraiment pas mal". Sur Hacker News, Alan Johnson, développeur logiciel chez The Hackerati, commente ainsi "ES6 est un vrai bol d'air pur".

Cependant, il y avait quand même de la confusion et de l'appréhension sur certaines parties.

Evan Winslow commente l'article de Rauschmayer ainsi :

Si l'export par défaut est un simple export nommé, qu'est-ce que cela apporte ? Cela signifie t-il implicitement que les exports nommés sont la manière préférée et que les exports par défaut sont simplement un hack par dessus ? Mais si vous utilisez System.import pour charger un module de manière asynchrone, vous devez utiliser .default pour obtenir l'export par défaut. C'est un peu perturbant.

Rauschmayer répond  :

La communauté JS est très variée et la réponse apportée par ES6 doit supporter un maximum de cas. Cela signifie que c'est légèrement plus compliqué que çà n'aurait pu l'être mais que çà a le potentiel d'unifier la communauté.

Les lecteurs InfoQ qui souhaiteraient soumettre des propositions pour ES7+ peuvent le faire sur ECMAScript6 Github.