Meteor améliore l'intégration de NPM, et refond sa gestion de paquets

Le Meteor Development Group a annoncé la sortie de Meteor 0.6.0 le 4 avril, cette nouvelle version inclus une refonte majeure du système de gestion des paquets et une intégration améliorée de NPM. Depuis cette sortie, la version0.6.2 parue le 16 avril inclus de nombreuses améliorations et correctifs.

Parce qu'il impose un modèle de développement synchrone dans Node.js avec Fibers et utilise un système de gestion de paquet spécifique, Meteor va à l'encontre de l'approche asynchrone classique de Node et impose sa vision, soulevant tout à la fois louanges et scepticisme. La version 0.6.0 fait oublier ces différends en se rapprochant de l'écosystème Node.js. Avital Oliver est le principal instigateur de la version 0.6.0, aidé de contributions majeures de David Glasser et du reste de l'équipe Meteor. InfoQ a rencontré Avital pour discuter des implications de la version 0.6.0 sur les communautés Meteor et Node.js.

InfoQ: L'une des critiques soulevées à l'encontre de Meteor tient dans l'utilisation d'une 'gestion de paquet propriétaire' -- Avec Meteor 0.6.0, en quoi la donne est elle changée ?

Avital: Eh bien, je ne vois pas trop en quoi les smart packages seraient plus 'propriétaires' que NPM, Bower, Component, ou tout autre gestionnaire de paquets moins connus. Les smarts packages sont fondamentalement différents des modules NPM par exemple. Une des propriétés remarquables des smart packages est qu'ils peuvent être exécutés aussi bien côté client, côté serveur, durant le build, et même s'intégrer à l'environnement de production. C'est ce qui fait que les commandes meteor add coffeescript, meteor add appcache et meteor add email fonctionnent, tout simplement. Geoff Schmidt [l'un des principaux développeurs de Meteor] a écrit une rapide explication sur ces différences.

InfoQ: Etant donné le manque de consistance des paquets NPM, lesquels sont les plus simples à wrapper via NPM.depends ? Est-ce que l'espace de nommage NPM dans Meteor offre une encapsulation additionnelle des fonctionnalités de NPM (par exemple pour s'assurer que les processus asynchrones sont convertis en Futures, etc.), ou cela incombe-t-il au wrapper NPM-Meteor ?

Avital: Nous allons clairement construire une sorte d'encapsulation générique, similaire à Future.wrap mais meilleure. Elle permettra de contourner certains cas aux limites de Future.wrap, et son interface permettra de fournir un callback optionnel, similaire à celle que nous avons pour l'appel coté serveur à Meteor.call et Meteor.http.call. D'ici là, le plus simple est d'utiliser future.resolver() (c'est l'approche retenue par l'exemple XML2JS).

Pour ce qui est de savoir quels modules NPM encapsuler, encapsulez simplement ceux que vous souhaitez utiliser ! Ça permettra à la communauté d'utiliser les outils dont elle a besoin dans Meteor, et ça nous aidera à identifier les fonctionnalités sur lesquelles nous devons concentrer nos efforts.

InfoQ: Quand est-il prévu de sortir la documentation du support NPM ?

Avital: Il le sera en même temps que la version finale de l'API Package sera documentée, et on y travaille activement (ce que l'on peut constater sur la branche linker du dépôt Github).

InfoQ: Meteor 0.6.0 vient avec un nouveau système de gestion de paquets dénommés Engine, qu'est-ce que c'est et en quoi est-il différent des versions précédentes ?

Avital: Nous nous attaquions à deux problèmes: (1) les applications devraient être attachées aux releases, et idéalement, vous ne devriez pas avoir à télécharger tous les packages à chaque fois que vous changez de release, et (2) Meteor devrait pouvoir supporter nativement l'intégration de paquets tierce partie. Afin d'atteindre ces deux objectifs, nous livrons les outils en ligne de commande Meteor séparément des paquets. Une release pointe juste vers des versions spécifiques de chaque outil et paquet. Quand vous lancez une nouvelle version de Meteor, nous téléchargeons uniquement les artifacts qui ont changé et les mettons en cache dans un entrepôt, situé dans ~/.meteor.

InfoQ: David Glasser a récemment mentionné que vous aviez toujours souhaité supporter NPM mais que vous vouliez le faire 'correctement' -- peux-tu nous expliquer ce que tu entends par là ?

Avital: Nous ne voulions pas demander aux gens de lancer des commandes NPM, de la même manière que nous ne leur demandons pas de lancer leur propre instance MongoDB. Nous lançons donc npm install et autre sous le capot à votre place. Nous utilisons également npm shrinkwrap afin de garantir qu'à chaque fois que vous utilisez un smart package, vous exécutez exactement le même code. Afin d'obtenir tout cela d'une manière complètement transparente, nous avons du faire quelques ajustements autour de NPM . Il y a également quelques détails supplémentaires, comme le fait que npm shrinkwrap ne vous permet pas de mettre à jour la version d'une seule dépendance à la fois. Quoi qu'il en soit, pour ceux qui sont curieux, le code qui implémente tout ceci est situé ici.

InfoQ: Comment justifiez-vous ces choix difficiles qui vont à l'encontre des conventions actuelles ? (Choisir votre propre système de gestion de paquets au lieu de NPM)

Avital: Le critère qui nous motive est toujours le même: offrir la meilleure expérience à nos utilisateurs.

InfoQ: Qu'est-il prévu par la suite pour le support NPM ?

Avital: Nous avons encore du travail à faire pour supporter les paquets qui ont des dépendances binaires. Nous les construirons toutes plateformes confondues sur nos serveurs afin que lorsque vous lancez 'meteor deploy', cela fonctionne même si votre machine tourne sur une architecture différente (par exemple un Mac). Comme évoqué plus haut, nous construirons également une encapsulation générique qui permettra de convertir simplement les API asynchrones typiques de Node vers des API avec callbacks optionnels.

InfoQ: Quand pouvons-nous espérer voir sortir Meteor 1.0 maintenant ?

Avital: Ce n'est ni trop proche ni trop lointain :)