¡Hola @zekth!

Emocionantes planes que tienes con deno en el futuro. Estoy muy seguro de que este proyecto es compatible con el módulo ES, y estoy completamente de acuerdo con sus pensamientos sobre cómo evitar un puerto.

¿Tiene alguna idea concreta sobre lo que sería necesario para que esto suceda?

Aquí hay un puerto (realmente feo) que hice esta mañana (en texto mecanografiado) https://github.com/zekth/deno_mustache/blob/master/mod.ts

He portado algunas pruebas solo para el principio.
La única preocupación que tengo son todos los entornos diferentes que admite con bigote, tener el módulo ES del archivo js principal compatible es mejor que otro mjs creo, pero no quiero romper nada :)

¡Muchas gracias por la referencia! 👍

Como no tengo experiencia con deno, lanzaré algunas preguntas triviales para desencadenar algunas discusiones:

1. ¿Qué requisitos debo tener para que esto funcione? ¿Necesita ser un archivo .mjs o le importa el type="module" de package.json ?
2. ¿Algún requisito de nomenclatura de archivos?
3. ¿TypeScript importa aquí de alguna manera?

..y así sucesivamente, cualquier pista para tontos sería muy apreciada. Por el momento, tengo muy poco conocimiento sobre deno para pensar de manera creativa sobre formas plausibles de abordar esto.

1. No hay ningún requisito especial ya que solo necesita que la biblioteca sea un módulo ES. Ejemplo lodash funciona sin ninguna portabilidad. La carga del módulo se realiza mediante la obtención de HTTP, sin paquete json ni nada.
2. Sin convención de nomenclatura
3. Puede usar TypeScript de JavaScript, Deno maneja ambos.

Por ejemplo, el uso de bigote en deno se vería así:

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

Si desea obtener más información, puede consultar esta charla de Ryan: https://www.youtube.com/watch?v=z6JRlx5NC9E

¡Frio!

Así que aquí hay algunas divagaciones para compartir algunos pensamientos y contexto. Mi comprensión de los módulos ES es que están destinados a ser sintácticamente analizables en términos de lo que es export ed. Eso es un contraste oscuro con sus precursores como CommonJS, AMD, etc., que es mucho más dinámico por naturaleza.

Con eso en mente, también estoy asumiendo que el IIFE que rodea el cuerpo de mustache.js hoy, destinado a detectar la función del sistema de módulo en el que se ejecuta el código actualmente, no funcionará en la tierra del módulo ES; corríjame si ' ¡Estoy mal!

Eso significa que tiene que haber un archivo .js | .mjs | .ts que tenga un export ... simple y llano como el que tiene en su puerto: zekth / deno_mustache / mod.ts # L689 .

La diversión comienza cuando también queremos mantener el comportamiento anterior, ser compatibles con proyectos que usan otros sistemas de módulos o ni siquiera un sistema de módulos, de ahí la necesidad de la envoltura IIFE mencionada: pensar: Y como recordatorio, eso significa proyectos ejecutándose en servidores y navegadores.

Dado que seguramente no queremos mantener dos implementaciones diferentes (módulos ES + el resto) sincronizadas, comienza a parecer que vale la pena considerar un paso de compilación. Por ejemplo, si escribimos el código fuente en el estilo del módulo ES, entonces un paso de compilación podría convertirlo en un módulo no ES como lo tenemos hoy. O al revés si eso es menos intrusivo.

Como nota final, soy un gran admirador de dar los pasos más pequeños posibles. En general, soy positivo con TypeScript, pero ¿está bien por ahora si nos mantenemos enfocados en los módulos ES y hacemos una ronda diferente enfocada en si convertir o no a TypeScript / exportar typedefs?

¿Algún otro pensamiento o corrección que le venga a la mente?

Tiene toda la razón, el primer paso sería agregar la pila de TypeScript y usar el compilador para generar múltiples archivos como commonjs / ES5 / ES6 y así sucesivamente (https://www.typescriptlang.org/docs/handbook/compiler-options .html). Usar el compilador TS no nos obliga a usar TypeScript, también podemos usar el código ES6.

¡Oh, esa es una gran sugerencia! Intentando usar el compilador TS como una herramienta de construcción ordinaria de ES -> otros sistemas de módulos al principio. Eso hará que una conversión de TS plausible más adelante sea mucho menos riesgosa.

¿Eres capaz de darle una oportunidad a ese enfoque? No necesariamente resolviendo todo de una vez, pero al menos los primeros bloques de construcción. Sería realmente valioso tener algo concreto en lo que mirar y basar las discusiones futuras.

Así que intenté hacer una transición a un módulo ES.

Mi prueba de concepto terminó usando rollup.js en lugar del compilador TypeScript (o babel) principalmente debido a la versión UMD que generan; todavía lo necesitamos para mantener la compatibilidad con sistemas de módulos más antiguos o sin ningún sistema de módulos.

¿Alguna posibilidad de que esté dispuesto a probarlo con deno para ver si funciona como espera? phillipj / mustache.js # esm-ify mustache.mjs

¡@phillipj servirá!

Algunos errores, pero creo que son correcciones menores:

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.

código:

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);

¿Quiere que intente hacer un PR en su archivo .mjs ?

¡Gracias!

Date cuenta ahora de que debería compartir un poco más de contexto sobre lo que intenté hacer inicialmente, lo siento.

Como discutimos anteriormente, mi intento inicial con el compilador de TypeScript también arrojó bastantes errores, algo similares a los que proporcionó ahora. Sin embargo, me sorprendió que generara resultados y se acercaran mucho a lo que quería.

Lo que no me gustó fue el código UMD que envolvía la salida compilada. Principalmente dos cosas:

1. No tiene el respaldo de exponer el contenido del paquete al alcance global (piense en window.Mustache ). Esto es vital para nuestros usuarios que no tienen un sistema de módulos en su lugar.
2. En proyectos con CommonJS, el contenido de este paquete se expone como module.exports.default lugar de module.exports . Aunque ese podría ser el comportamiento correcto y esperado cuando CommonJS require() s es un módulo ES, romperá la compatibilidad con versiones anteriores, lo que esperaba evitar.

Como mi objetivo principal era, ante todo, hacer la transición del código fuente a un módulo ES, sin introducir TypeScript, decidí probar diferentes compiladores / agrupadores para ver si hacían las cosas de manera diferente para evitar los dos desafíos anteriores.

De ahí la razón por la que terminé con rollup.js. Su salida UMD es lo que necesitamos y no causa ningún cambio importante a los usuarios de este paquete.

Tan a mi pregunta real; ¿Tenemos que preocuparnos por TypeScript en este momento?

Lo que entendí anteriormente en esta discusión fue que podríamos considerar no realizar una transición completa a TypeScript todavía, ya que ayudaría a deno todos modos si de hecho es un módulo ES, pero ¿podría haberlo entendido mal un poco?

Creo que el principal problema es la primera inicialización del bigote como aquí:
https://github.com/janl/mustache.js/blob/master/mustache.js#L14

y también esto: https://github.com/janl/mustache.js/blob/master/mustache.js#L536
se puede reescribir como new Context(view, null)

¿no crees?

Creo que el principal problema es la primera inicialización del bigote.

Probablemente tengas razón. En la versión .mjs intenté mover eso al código fuente real al menos, en lugar de ser un objeto pasado desde el contenedor UMD:

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

Sería genial ver su enfoque que solucionaría esos errores de TypeScript 👍

se puede reescribir como nuevo contexto (vista, nulo)

Casi ... ¿No es new Context(view, undefined) el equivalente a no pasar un segundo argumento en absoluto?

Sí, correcto sobre el new Context

Intentaré algo así :)

Aquí está el PR: https://github.com/phillipj/mustache.js/pull/1
CI está roto pero no entiendo por qué recibí esos mensajes borrosos

¡Increíble, muchas gracias! Bastante ocupado los próximos días, haré todo lo posible para revisar antes de que termine la semana.

Actualización de estado; como mencioné en el PR que abrió contra mi rama esm-ify , ahora tengo algunas pruebas implementadas que garantizan que este paquete funcione según lo previsto para los diferentes sistemas de módulos que hemos admitido durante años en el n. ° 724.

Dejaré que se elabore durante un par de días, ya que solo presioné algunas mejoras, en caso de que alguien tenga alguna objeción o más ajustes en mente.

Con esas pruebas en su lugar, me siento cómodo avanzando en la transición de este proyecto a tener el código fuente escrito como un módulo ES y paso de compilación para producir lo que tenemos en mustache.js hoy; eso, por supuesto, se hará en un próximo PR.

728 ha sido abierto al escrutinio público.