Salut @zekth !

Des projets passionnants que vous avez avec deno pour l'avenir. Je suis très heureux de rendre ce module ES de projet compatible, et je suis tout à fait d'accord avec vos réflexions sur l'évitement d'un port.

Avez-vous des idées concrètes sur ce qui serait nécessaire pour que cela se produise ?

Voici un portage (vraiment moche) que j'ai fait ce matin (en tapuscrit) https://github.com/zekth/deno_mustache/blob/master/mod.ts

J'ai porté quelques tests juste pour le début.
La seule préoccupation que j'ai est tous les différents environnements que vous supportez avec moustache, avoir le principal module ES de fichier js compatible est mieux qu'un autre mjs je pense mais je ne veux rien casser :)

Merci beaucoup pour la référence ! ??

Comme je n'ai aucune expérience avec deno, je vais poser quelques questions triviales pour déclencher des discussions :

1. Quelles sont les conditions requises pour que cela fonctionne ? Est-ce que ce doit être un fichier .mjs ou est-ce que ça se soucie du type="module" de package.json ?
2. Des exigences de nommage des fichiers ?
3. TypeScript est-il important ici d'une manière ou d'une autre ?

..et ainsi de suite, tout indice pour les nuls serait très apprécié. Pour le moment, j'ai trop peu de connaissances sur deno pour réfléchir de manière créative à des moyens plausibles de résoudre ce problème.

1. Il n'y a pas d'exigence particulière car il suffit que la bibliothèque soit un module ES. L'exemple lodash fonctionne sans aucun portage. Le chargement du module se fait par récupération HTTP, pas de package json ou quoi que ce soit.
2. Aucune convention de nommage
3. Vous pouvez utiliser TypeScript de JavaScript, Deno gère les deux.

Par exemple, l'utilisation de la moustache dans deno ressemblerait à :

import * as mustache from 'https://raw.githubusercontent.com/janl/mustache.js/master/mustache.js'
mustache.render(......

Si vous voulez plus d'informations, vous pouvez consulter cette conférence de Ryan : https://www.youtube.com/watch?v=z6JRlx5NC9E

Cool!

Voici donc quelques divagations pour partager quelques réflexions et contexte. Ma compréhension des modules ES est qu'ils sont censés être syntaxiquement analysables en termes de export ed. C'est un contraste sombre avec ses précurseurs comme CommonJS, AMD, etc., qui sont de nature beaucoup plus dynamique.

Dans cet esprit, je suppose également que l' IIFE entourant le corps de moustache.js aujourd'hui, destiné à détecter le système de module dans lequel le code s'exécute actuellement, ne fonctionnera pas dans le module ES -- veuillez me corriger si je ' je me trompe !

Cela signifie qu'il doit y avoir un fichier .js | .mjs | .ts qui a un simple export ... comme vous l'avez dans votre port : zekth/deno_mustache/mod.ts#L689 .

Le plaisir commence lorsque nous voulons également conserver l'ancien comportement, rester compatible avec les projets utilisant d'autres systèmes de modules ou même pas un système de modules du tout, d'où la nécessité du wrapper IIFE mentionné :réflexion: Et pour rappel, cela signifie des projets fonctionnant sur des serveurs et des navigateurs.

Étant donné que nous ne voulons sûrement pas garder deux implémentations différentes (modules ES + le reste) synchronisées, il commence à sembler qu'il vaut la peine d'envisager une étape de construction. Par exemple, si nous écrivions le code source dans le style du module ES, une étape de construction pourrait le convertir en module non-ES comme nous l'avons aujourd'hui. Ou l'inverse si c'est moins intrusif.

Pour terminer, je suis un grand fan de faire le plus petit nombre possible. Je suis généralement favorable à TypeScript, mais est-ce que ça va pour le moment si nous continuons à nous concentrer sur les modules ES et faisons un tour différent axé sur la conversion ou non en TypeScript/exporter les définitions de type ?

D'autres réflexions ou corrections vous viennent à l'esprit ?

Vous avez tout à fait raison, la première étape serait d'ajouter la pile TypeScript et d'utiliser le compilateur pour générer plusieurs fichiers comme commonjs / ES5 / ES6 et ainsi de suite ( https://www.typescriptlang.org/docs/handbook/compiler-options .html). L'utilisation du compilateur TS ne nous oblige pas à utiliser TypeScript, nous pouvons également utiliser le code ES6.

Oh c'est une super suggestion ! Essayer d'utiliser le compilateur TS comme un outil de construction ordinaire à partir d'ES -> d'autres systèmes de modules au début. Cela rendra une conversion TS plausible plus tard beaucoup moins risquée.

Êtes-vous capable de donner une chance à cette approche? Pas nécessairement tout résoudre en une seule fois, mais au moins les premiers éléments constitutifs. Ce serait vraiment utile d'avoir quelque chose de concret à examiner et de baser les discussions futures.

Sooo J'ai essayé de faire une transition vers un module ES.

Ma preuve de concept a fini par utiliser rollup.js au lieu du compilateur TypeScript (ou babel) principalement à cause de la version UMD qu'ils génèrent - nous en avons toujours besoin pour conserver la compatibilité avec les systèmes de modules plus anciens ou aucun système de modules du tout.

Avez-vous une chance de le tester avec deno pour voir s'il fonctionne comme vous l'espériez ? phillipj/moustache.js#esm-ify moustache.mjs

@phillipj fera l'affaire !

Quelques erreurs mais je pense que ce sont des corrections mineures :

error TS2339: Property 'render' does not exist on type '{ name: string; version: string; tags: string[]; }'.

► file:///Users/vlegoff/projects/genesys/github/telemetry/t/mustache.ts:10:23

10 var output = mustache.render('{{title}} spends {{calc}}', view);
                         ~~~~~~

error TS2554: Expected 2 arguments, but got 1.

► https://raw.githubusercontent.com/phillipj/mustache.js/esm-ify/mustache.mjs:525:52

525   var context = (view instanceof Context) ? view : new Context(view);
                                                       ~~~~~~~~~~~~~~~~~

  An argument for 'parentContext' was not provided.

    ► https://raw.githubusercontent.com/phillipj/mustache.js/esm-ify/mustache.mjs:377:25

    377 function Context (view, parentContext) {
                                ~~~~~~~~~~~~~


error TS2339: Property 'escape' does not exist on type '{ name: string; version: string; tags: string[]; }'.

► https://raw.githubusercontent.com/phillipj/mustache.js/esm-ify/mustache.mjs:640:21

640     return mustache.escape(value);
                        ~~~~~~

error TS2339: Property 'clearCache' does not exist on type '{ name: string; version: string; tags: string[]; }'.

► https://raw.githubusercontent.com/phillipj/mustache.js/esm-ify/mustache.mjs:659:10

659 mustache.clearCache = function clearCache () {
             ~~~~~~~~~~

error TS2339: Property 'parse' does not exist on type '{ name: string; version: string; tags: string[]; }'.

► https://raw.githubusercontent.com/phillipj/mustache.js/esm-ify/mustache.mjs:668:10

668 mustache.parse = function parse (template, tags) {
             ~~~~~

error TS2339: Property 'render' does not exist on type '{ name: string; version: string; tags: string[]; }'.

► https://raw.githubusercontent.com/phillipj/mustache.js/esm-ify/mustache.mjs:678:10

678 mustache.render = function render (template, view, partials, tags) {
             ~~~~~~

error TS2339: Property 'to_html' does not exist on type '{ name: string; version: string; tags: string[]; }'.

► https://raw.githubusercontent.com/phillipj/mustache.js/esm-ify/mustache.mjs:690:10

690 mustache.to_html = function to_html (template, view, partials, send) {
             ~~~~~~~

error TS2339: Property 'render' does not exist on type '{ name: string; version: string; tags: string[]; }'.

► https://raw.githubusercontent.com/phillipj/mustache.js/esm-ify/mustache.mjs:693:25

693   var result = mustache.render(template, view, partials);
                            ~~~~~~

error TS2339: Property 'escape' does not exist on type '{ name: string; version: string; tags: string[]; }'.

► https://raw.githubusercontent.com/phillipj/mustache.js/esm-ify/mustache.mjs:704:10

704 mustache.escape = escapeHtml;
             ~~~~~~

error TS2339: Property 'Scanner' does not exist on type '{ name: string; version: string; tags: string[]; }'.

► https://raw.githubusercontent.com/phillipj/mustache.js/esm-ify/mustache.mjs:707:10

707 mustache.Scanner = Scanner;
             ~~~~~~~

error TS2339: Property 'Context' does not exist on type '{ name: string; version: string; tags: string[]; }'.

► https://raw.githubusercontent.com/phillipj/mustache.js/esm-ify/mustache.mjs:708:10

708 mustache.Context = Context;
             ~~~~~~~

error TS2339: Property 'Writer' does not exist on type '{ name: string; version: string; tags: string[]; }'.

► https://raw.githubusercontent.com/phillipj/mustache.js/esm-ify/mustache.mjs:709:10

709 mustache.Writer = Writer;
             ~~~~~~


Found 12 errors.

code:

import mustache from 'https://raw.githubusercontent.com/phillipj/mustache.js/esm-ify/mustache.mjs';

var view = {
  title: 'Joe',
  calc: function() {
    return 2 + 4;
  },
};

var output = mustache.render('{{title}} spends {{calc}}', view);

console.log(output);

voulez-vous que j'essaye de faire un PR sur votre fichier .mjs ?

Merci!

Réalisez maintenant que je devrais partager un peu plus de contexte sur ce que j'ai essayé de faire au départ, désolé.

Comme nous en avons discuté plus tôt, ma première tentative avec le compilateur TypeScript a également donné quelques erreurs, quelque peu similaires à celles que vous avez fournies maintenant. Néanmoins, cela m'a surpris qu'il génère une sortie et qu'il soit très proche de ce que je voulais.

Ce qui ne m'a pas plu, c'est le code UMD qu'il enroulait autour de la sortie compilée. Principalement deux choses :

1. Il n'a pas la possibilité d'exposer le contenu du package sur la portée globale (pensez à window.Mustache ). Ceci est vital pour nos utilisateurs qui n'ont pas de système de module en place.
2. Dans les projets avec CommonJS, le contenu de ce package est exposé sous la forme module.exports.default plutôt que module.exports . Bien que cela puisse être le comportement correct et attendu lorsque CommonJS require() est un module ES, il rompra la compatibilité descendante, ce que j'espérais éviter.

Comme mon objectif principal était avant tout de transformer le code source en un module ES, sans introduire TypeScript, j'ai décidé d'essayer différents compilateurs/groupeurs pour voir s'ils faisaient les choses différemment pour éviter les deux défis ci-dessus.

D'où la raison pour laquelle je me suis retrouvé avec rollup.js. C'est la sortie UMD dont nous avons besoin et elle n'entraîne aucun changement majeur pour les utilisateurs de ce package.

Sooo à ma question réelle; devons-nous nous soucier de TypeScript pour le moment ?

D'après ce que j'ai compris plus tôt dans cette discussion, nous pouvions envisager de ne pas encore passer complètement à TypeScript, car cela aiderait néanmoins deno s'il s'agit bien d'un module ES, mais j'ai peut-être mal compris cela un peu ?

Je pense que le problème principal est la première initialisation de moustache comme ici :
https://github.com/janl/mustache.js/blob/master/mustache.js#L14

et aussi ceci : https://github.com/janl/mustache.js/blob/master/mustache.js#L536
peut être réécrit comme new Context(view, null)

tu ne penses pas ?

Je pense que le problème principal est la première initialisation de moustache ..

Tu as probablement raison. Dans la version .mjs , j'ai essayé de déplacer cela au moins dans le code source réel, au lieu d'être un objet transmis depuis le wrapper UMD :

var mustache = {
  name: 'mustache.js',
  version: version,
  tags: [ '{{', '}}' ]
}

Ce serait cool de voir votre approche qui corrigerait ces erreurs TypeScript 👍

peut être réécrit en tant que nouveau contexte (vue, null)

Presque... new Context(view, undefined) n'est-il pas l'équivalent de ne pas passer du tout un deuxième argument ?

Oui correct pour le new Context

Je vais essayer quelque chose alors :)

Voici le PR : https://github.com/phillipj/mustache.js/pull/1
CI est cassé mais je ne comprends pas pourquoi j'ai reçu ces messages linting

Génial, merci beaucoup ! Assez occupé les deux prochains jours, je ferai de mon mieux pour réviser avant la fin de la semaine.

Mise à jour du statut; comme je l'ai mentionné dans le PR que vous avez ouvert contre ma branche esm-ify , j'ai maintenant mis en place quelques tests qui garantissent que ce package fonctionne comme prévu pour les différents systèmes de modules que nous avons pris en charge pendant des années dans #724.

Je vais laisser cette infusion pendant quelques jours car je viens de pousser quelques améliorations, juste au cas où quelqu'un aurait des objections ou d'autres ajustements en tête.

Avec ces tests en place, je me sens à l'aise de faire la transition de ce projet vers l'écriture du code source en tant que module ES et l'étape de construction pour produire ce que nous avons dans mustache.js aujourd'hui -- ce sera bien sûr fait dans un prochain PR.

728 a été ouvert à l'examen public.