Less.js: ES6 y resumen

No. He estado pensando en la misma línea por un tiempo. ¿Qué pasa con el uso de TypeScript? Podría facilitar el desarrollo/las contribuciones tener sugerencias de código/vinculación de objetos reales. Aunque no sé si esto pondría una carga/barrera de conocimiento entonces.

También estaba pensando en la misma línea que deberíamos considerar usar colecciones es6 para analizar / AST y luego usar un polyfill para compilaciones es5 como https://github.com/Benvie/harmony-collections. En entornos es6 (que ahora es Node.js, al igual que los navegadores más recientes), eso teóricamente debería acelerar el análisis/evaluación debido a la sobrecarga de memoria reducida y la construcción AST más rápida.

¿Qué pasa con el uso de TypeScript? Podría facilitar el desarrollo/las contribuciones tener sugerencias de código/vinculación de objetos reales. Aunque no sé si esto pondría una carga / barrera de conocimiento entonces.

Podemos considerar que después de ES6, es6 no excluye el mecanografiado, ya que el mecanografiado también es un transpilador de es6... sería un paso adicional después de esto.

Personalmente, no recomendaría mecanografiado a menos que hubiera un trabajo adicional significativo o una refactorización en menos. Texto mecanografiado de la OMI

• + facilita el desarrollo para nuevas personas que saben mecanografiar
• + aumenta la mantenibilidad
• 
  
  • requiere que las personas sepan o aprendan una cantidad mínima de texto mecanografiado
  
  
• 
  
  • lleva más tiempo escribir el código para que se escriba
  
  

También estaba pensando en la misma línea que deberíamos considerar usar colecciones es6 para analizar / AST y luego usar un polyfill para compilaciones es5 como https://github.com/Benvie/harmony-collections. En entornos es6 (que ahora es Node.js, al igual que los navegadores más recientes), eso teóricamente debería acelerar el análisis/evaluación debido a la sobrecarga de memoria reducida y la construcción AST más rápida.

No usaría ese polyfill, el proyecto parece muerto (quizás también porque el nombre armonía está muerto).

Además, lamentablemente no estaría seguro de que los equivalentes nativos de ES6 sean más rápidos: https://jsperf.com/property-access-object-array-map-weakmap/6. Es triste cómo, por ejemplo, Promise polyfill es más rápido que la implementación nativa :(

:+1:

Todos los buenos puntos. La estandarización en ES6 / Babel a menudo hace que las cosas no solo sean más fáciles de escribir, sino también de leer, especialmente cuando se hace una herencia prototípica.

En cuanto a esa prueba jsperf, no es realmente un buen ejemplo. Espero que Weakmap funcione más lento para esa prueba específica. En teoría, podría ser mejor para Less crear un montón de formas y tipos de objetos diferentes y luego evaluarlos. Aunque no estoy seguro. Encontré algunas bibliotecas buenas que quiero probar eventualmente (y espero agregar) donde podemos conectarnos a funciones individuales para hacer una evaluación comparativa granular, sin tener que poner ningún "gancho de evaluación comparativa" en la biblioteca. Espero configurar algo (cuando tenga tiempo, quién sabe cuándo será) para que pueda hacer una especie de prueba jsperf en funciones dentro de Less.js, pero con desarrollo local/cambios de rama a Less vs. the versión actual y usando algunos tipos de archivos de prueba .less. Como mencioné antes, no deberíamos tener que adivinar cuál es más rápido para nuestro caso de uso particular. En teoría, podríamos subdividirnos en un WeakMap en algún nivel de función frente a objetos sin procesar, ejecutar puntos de referencia en esa ubicación y decidir según el resultado.

@lukeapage escribió:
Texto mecanografiado de la OMI

• + facilita el desarrollo para nuevas personas que saben mecanografiar
• + aumenta la mantenibilidad
• 
  
  • requiere que las personas sepan o aprendan una cantidad mínima de texto mecanografiado
  
  
• 
  
  • lleva más tiempo escribir el código para que se escriba
  
  

Y un beneficio muy significativo que no se menciona que está pasando por alto:
El modo tipeado de TypeScript lo obliga a usar tipos de variables estables, lo que impone formas de tipos estables, lo que mejora la capacidad del compilador para analizar su código de forma estática _y_ dinámica, lo que produce un código optimizado _mucho mejor_ y detiene (o al menos reduce drásticamente) las reversiones de código optimizado de vuelta al código interpretado lento.

Mudarse a TypeScript probablemente contribuiría más que mudarse a ES6, en mi humilde opinión.

Por modo escrito te refieres a prohibir ¿Alguno?

Probé eso en un proyecto pequeño y tenía anotaciones en todas partes... termina
con un montón de código porque el transpilador no es muy inteligente.

en cuanto a cuántas variables tienen tipos de variables mutadas, no estoy seguro. entonces..
no estoy convencido de que el beneficio de rendimiento sea notable.

@rjgotten No he usado TypeScript pero esos son buenos puntos. Si está utilizando un entorno de intellisense/autocompletar para TypeScript, en realidad podría ayudar a los nuevos colaboradores, ya que completaría tipos/formas de objetos a medida que realiza cambios. Con un diseño adecuado, podría servir como una especie de herramienta de autodocumentación/familiarización/prevención de errores para alguien que contribuya con cambios de código. Pero la clave probablemente esté en el diseño de TypeScript.

En general, ¿habría un beneficio de rendimiento? Eso es más difícil de determinar. Eso es más el artista que el lienzo.

Aunque pretendo usar TypeScript para mis propios proyectos, probablemente esté un poco más inclinado a estar de acuerdo con @lukeapage , principalmente porque, a menos que alguno de nosotros aquí sea experto en TypeScript, no estoy seguro de que podamos hacer un uso efectivo. de ella inicialmente.

Además, pasar a ES6 no impide usar TypeScript en el futuro. El objetivo de Microsoft/Google es hacer de TypeScript 2.0 un superconjunto de ES6, por lo que siempre podemos comenzar con ES6/Babel y luego agregar los tipos adecuados y cambiar al transpilador de TypeScript. Mi sospecha es que TypeScript va a "ganar" los idiomas transpilados, solo porque los beneficios de tiempo de compilación / autocompletado son mucho mayores que los de JavaScript sin tipo. Entonces... Supongo que eso significa que creo que usar TypeScript es probablemente inevitable, pero eso no significa que tengamos que usarlo de inmediato.

Me gustaría discutir un enfoque arquitectónico diferente a Less en algún momento, pero eso es más una discusión tangente a esto.

Por modo escrito te refieres a prohibir ¿Alguno?

No. Solo usando variables tipeadas en general. Usted _puede_ prohibir el uso de Any en general, pero es (al menos en la práctica) una mala idea porque tiende a generar una gran cantidad de código para satisfacer el sistema de escritura.

Sin embargo, el uso de parámetros escritos en una función significa que las personas que llaman (al menos las personas que llaman escritas en TypeScript) _deben_ respetar el tipo dado. Eso significa que las funciones tipadas se pueden usar para proteger la estabilidad de tipos en el funcionamiento interno del compilador Less cuando sea apropiado y garantizar que las funciones particularmente importantes estarán bien optimizadas. (No lo olvide; los motores JS generalmente se optimizan a nivel de función...)

el trabajo comenzó - https://github.com/less/less.js/tree/rollup

Muy buen trabajo. Germaine a la discusión, estaba mirando el código y rápidamente encontré:

if (typeof index === 'number') {   

AFAIK ese tipo de control de cordura nunca sería necesario en TypeScript. Si el tipo de índice se convierte en tiempo de ejecución en una cadena cada vez que se realiza una comparación de cadenas para verificar el tipo de valor, cosas como esa pueden sumarse. En TypeScript, si había una llamada a una función que pasaba un índice, pero ese tipo a veces no era un número, y el índice solo _aceptaba_ un número, entonces la función fallaría en tiempo de compilación debido a tipos no coincidentes, en lugar de necesitar para ser probado en tiempo de ejecución, cuando dichas comprobaciones son más caras.

Por otro lado, podría ser que este sea un ejemplo aislado y raro; es solo algo que encontré que parecía relevante.

Creo que la mayor ventaja de los tipos explícitos es que permiten herramientas más potentes. Encontrar todos (y solo) los lugares que llaman a una función o la anulan es solo un atajo de teclado. Averiguar qué funciones tienen los objetos que tiene disponibles es cero trabajo y la refactorización es más segura porque el compilador genera más errores. También hace que sea más fácil aprender una nueva base de código: obtener una imagen general, descubrir qué parte del código depende o seguir el flujo del código sin ejecutarlo es más difícil en javascript que en java (por ejemplo), porque los editores escritos son más poderosos.

Todavía no usé TypeScript, por lo que no sé si las herramientas son lo suficientemente maduras como para que valga la pena. La ventaja de javascript es que todo el mundo lo conoce, TypeScript es menos conocido.

En general, creo que cambiar a TypeScript tendría sentido si planeáramos algún tipo de refactorización más grande o nuevas funciones enormes, pero podría ser demasiado trabajo mientras solo arreglamos pequeños errores.

Creo que cambiar a TypeScript tendría sentido si planeáramos algún tipo de refactorización más grande o nuevas características enormes, pero podría ser demasiado trabajo mientras solo arreglamos pequeños errores.

Este puede ser el caso, y realmente, para ser pragmáticos, @lukeapage ya se ha hecho cargo del trabajo, así que me inclino a decir que debería tomar la decisión final en este momento. :-)

Oye, sobre esto: ¿hay algo que debamos hacer para que la gente sepa que el código base está cambiando? Supongo que de lo contrario tendrás conflictos de fusión.

no, no debería haber demasiados conflictos. el primer paso es solo módulos es6 - no
moviendo cualquier archivo, entonces podemos agregar babel o mecanografiado de forma transparente.

Hola, chicos, ¿cómo van ahora?

Puedo trabajar en esto. @ matthew-dean ¿Aceptaría una solicitud de extracción?

@alexlur Seguro! Mi única preocupación es la refactorización de la rama 3.x y no tener conflictos de fusión. Así que es mejor bifurcarse/ramificarse desde allí. Además, desde que se escribió este problema, ahora existe una convención bien establecida de usar src/ y dist/ . Sin embargo, lib/ a veces se usa como src/ , por lo que probablemente no sea necesario cambiar el nombre.

También habría una pequeña reescritura del Gruntfile para que las pruebas usen compilaciones y no lib/ . (Lo que hace la prueba del navegador es compilar en test/ y no dist/ . La carpeta dist/ es una tarea especial de Grunt para nuevas versiones. Al realizar la prueba, debe compilarse para test/ ) Después de hacer eso, mientras pases las pruebas, deberías estar bien.

@ matthew-dean Hola. Terminé con la refactorización, pero no sé cómo configurar Gruntfile para ejecutar pruebas en los nuevos archivos creados.

Tal vez lo que puedo hacer es fusionar sus cambios en una rama separada y ver cómo se integran las pruebas. Estaba revisando rápidamente tus cambios. Corrígeme si me equivoco, pero ¿es at-rule incorrectamente el nodo assignment ? ¿O Github simplemente estaba arruinando la forma en que mostraba eso?

Buena captura, usé el archivo equivocado.

¿Existe una versión mínima del navegador/Node.js que deba ser compatible con less.js? Node.js tiene un soporte bastante bueno para Promise (desde 0.12), mientras que el uso del navegador es generalmente para desarrolladores que ya ejecutan las últimas versiones del navegador de todos modos.

Editar:

Less.js es compatible con todos los navegadores modernos (versiones recientes de Chrome, Firefox, Safari, IE11+ y Edge)

Solo Internet Explorer 11 no tiene Promise integrado.

@alexlur
Para la versión en el navegador de Less, sugiero crear una propiedad less.Promise y establecerla en window.Promise de forma predeterminada. Y luego haga que Less consuma la clase Promise a través less.Promise .

De esta manera, los usuarios de navegadores modernos, así como los usuarios que tienen Promise polillenado globalmente antes de que se cargue Less, tendrán todo funcionando mágicamente. Y los usuarios que no quieren, o por cualquier motivo no tienen permitido hacerlo, polyfill globalmente pueden hacer que las cosas funcionen con un pequeño paso adicional. Solo necesitan asignar manualmente la implementación de Promise elegida a less.Promise antes de usar Less.

@rjgotten @alexlur Less.js ya tiene Promise polyfills ya configurados. No hay necesidad de hacer ningún trabajo adicional allí. La mayor parte del código usa este patrón:

https://github.com/less/less.js/blob/55380d49e96a6ed561cac4d13a774830aa3c17a3/lib/less/import-manager.js#L5

En el lado del nodo, todavía hay este problema abierto: https://github.com/less/less.js/issues/3121

Sin embargo, sin comentarios y con una cantidad bastante moderada de colaboradores, me inclino a decir que Node 4+ es el camino a seguir por ahora. Deberíamos actualizar documentos/pruebas para reflejar eso.

@ matthew-dean Debería estar listo para fusionarse en una rama separada .

@alexlur Gracias! Intentaré echar un vistazo pronto. Probablemente será la próxima semana (a menos que alguien más tenga la holgura para comprobarlo).

Este problema se ha marcado automáticamente como obsoleto porque no ha tenido actividad reciente. Se cerrará si no se produce más actividad. Gracias por sus aportaciones.

Creé una bifurcación refactorizada a TypeScript.

Creé una bifurcación refactorizada a TypeScript.

@glixlur 😮 guau, y pasan todas las pruebas? ¿Y construye un less.js idéntico en dist/ ?

@ matthew-dean Todavía estoy trabajando en ello, pero mi compilación para el navegador no ha encontrado ningún problema hasta ahora como controlador diario. Técnicamente, el uso de resumen le da a mi bifurcación una ventaja en el rendimiento, pero no tengo datos para respaldarlo.

@less/core Esto debe investigarse para ver si podemos automatizarlo para una conversión única: https://github.com/lebab/lebab

@ matthew-dean Te enviaré una solicitud de extracción una vez que haya terminado.

@glixlur Ah! Vale, en tu PR anterior , dijiste que no tenías tiempo para esto. Si todavía estás trabajando en esto, 👍

@ matthew-dean Me limitaré a simplemente convertir a ES6 y dejaré la parte de TypeScript más tarde.

@glixlur Creo que ES6 es probablemente el primer paso más "amigable para la comunidad", así que es perfecto. No estoy seguro de que todos estén de acuerdo con TypeScript, pero definitivamente un flujo de ES6 sería genial.

@ matthew-dean Supongo que las plataformas compatibles más bajas son Node 6 e IE11.

@glixlur Appveyor está configurado actualmente para probar el Nodo 4. ¿Haría eso las cosas más difíciles? Lo ideal sería que Babel transformara una carpeta src/ en (reemplazada) carpeta(s) lib/ (y dist/ para el navegador) para su distribución para el nodo/navegador. Así que asumiría que Babel está haciendo la mayor parte del trabajo de transpilación a ES5.

Listo , pero necesita que las pruebas funcionen. PhantomJS está obsoleto y no tiene soporte para nada después de ES5.

@glixlur Genial ! Re: PhantomJS, realmente necesita ser reemplazado por algo como Chromy. Ver: https://github.com/less/less.js/issues/3240

@glixlur Además, esto está relacionado con Chromy / Chrome sin cabeza: https://github.com/less/less.js/issues/3262

@glixlur Con respecto a PhantomJS: esas pruebas se ejecutan en la versión del navegador incluido, que presumiblemente estaría transpilando a ES5, ¿correcto? ¿Por qué PhantomJS no funcionaría con el paquete de salida ES5?

@matthew-dean Sí, pero hay un error en el que se usa Symbol cuando se ejecuta PhantomJS con un archivo transpilado por Babel.

@glixlur Necesita el babel-polyfill en la salida transpilada. Ese es un buen indicador de que aún no se está transpilando correctamente. Ver problemas como: https://github.com/babel/babel-preset-env/issues/203

@glixlur https://babeljs.io/docs/en/babel-polyfill/

@matthew-dean babel-polyfill agrega 87,3 KB minimizados al archivo de salida. Probablemente no quieras eso.

@glixlur
Hay otras razones por las que no desea babel-polyfill . A saber, el hecho de que afecta el espacio de nombres global al publicar polyfills en window y modificar los prototipos de tipos nativos como Array .

Busque babel-runtime y el paquete babel-plugin-transform-runtime en su lugar.

Además, el equipo de Babel de iirc está trabajando para limitar los polyfills agrupados por transform-runtime en la misma línea que las transformaciones de lenguaje de límites preestablecidos babel-env . Pero su trabajo aún no está terminado y generalmente no está disponible. Terminaría siendo una cosa de Babel 7, que de todos modos todavía está en versión beta, por lo que no es directamente útil. Pero definitivamente deseable para el futuro.

@glixlur @rjgotten Ah. Debería haber aclarado que no sé exactamente qué solución usar re: Babel. Solo que es porque Symbol no está definido porque no está polillenado (¿ponyfill?), que también estaría en IE11. Entonces, tal vez no sea el polyfill, pero creo que con la configuración correcta de Babel, debería darle una definición de alcance Symbol . Entonces, ¿quizás el problema sea la versión mínima del navegador?

con la configuración correcta de Babel, debería darle una definición Symbol alcance

De hecho lo hará.
Esas configuraciones equivalen a usar el complemento transform-runtime y su capacidad para inyectar alias para funciones integradas más nuevas como Symbol , en lugar de confiar en babel-polyfill .

¿Deberían quedar obsoletos los phantomjs?

¿Considerando que está muerto?
Probablemente si.

@glixlur Ver: https://github.com/less/less.js/issues/3240

¡Conversión hecha y fusionada! Ver: https://github.com/less/less-meta/issues/32

Bueno, esta semana aprendí que Class en JavaScript NO es simplemente azúcar sintáctico para prototipos de funciones, lo que causó este problema: https://github.com/less/less.js/issues/3414

Irónicamente, me encontré con lo mismo con otro fragmento de código no relacionado con Less, hace como 2 semanas y recuerdo claramente el pensamiento que me golpeó:

Caramba, me pregunto si esa conversión de ES6 por Less causaría este tipo de problema.

Bueno: pregunta respondida, supongo.

Yo _así que_ no envidio la tormenta de usuarios que expresaron su descontento por tu trabajo, @matthew-dean. Tienes mi simpatía por tener que manejar esa situación. :sonrisa:
Afortunadamente, parece que nadie se volvió apocalíptico y se manejó de manera ordenada.

@rjgotten lol Quiero decir, ¿cómo puedes anticipar algo así? Lo más seguro hubiera sido no convertir en absoluto, o nunca usar clases, pero hace que el código base sea menos detallado (bueno, o potencialmente lo hará, hay muchas oportunidades para una mayor limpieza). Técnicamente, la integración (histórica) less-loader con Less estaba haciendo un mal uso de la API (usando un uso no documentado/no compatible de la API), por lo que fue un error de su parte, pero simpatizo con la gente que se siente frustrada porque un lanzamiento de punto no importante que causa una falla de compilación.

Por ejemplo, si alguien piratea los prototipos en su biblioteca, ¿cómo codifica a la defensiva para eso?

🤷‍♂

@rjgotten

Técnicamente, lancé dos versiones beta después de la conversión, PERO... nadie tiene Menos betas en preparación. Por lo tanto, no hay forma de probar 800 000 repositorios que se integran con Less y ejecutar sus pruebas. Con las dependencias de NPM, realmente tienes que ponerlo ahí y ver qué falla.

Una cosa que podríamos hacer en el futuro es agregar algunos menos dependientes más grandes a las pruebas, si podemos averiguar cuáles son.

La otra cosa que podría haber hecho es lanzarlo como una versión principal, pero... técnicamente NO tiene ningún cambio importante (intencional), es decir, las características admitidas son idénticas e incluye algunas correcciones de errores, así que... .. No sé, esto fue complicado.

Sí. Fue complicado.

Supongo que podrías haber intentado poner algo en una etiqueta .next o algo así y hacer que la gente se dé cuenta de que prueben sus canalizaciones de compilación con él. Pero las experiencias pasadas indican que ese tipo de cosas generalmente no se escuchan.

De cualquier manera, versión principal o no, probablemente terminará viéndose obligado a simplemente "probarlo" y ver qué falla.

Sin embargo, no me malinterpreten: el refactor es algo muy bueno. En el futuro, generalmente debería quitar una buena parte de la carga de mantenimiento.

Por ejemplo, si alguien piratea los prototipos en su biblioteca, ¿cómo codifica a la defensiva para eso?

Literalmente no lo haces.

Es como si la gente se quejara de que su IL emitido en tiempo de ejecución cuidadosamente orquestado para acceder a miembros privados en C# se interrumpe en versiones menores. Si te entrometes con cosas internas, debes saber en lo que te estás metiendo. :sonrisa:

@rjgotten Hablando de refactorización...

..... Una de las cosas que he descubierto con el tiempo en el código base de Less es que hay varios lugares donde hay mutaciones leves/sutiles en los objetos en el AST. Una nueva propiedad aquí / un método agregado en una instancia allá, y admitiré plenamente haber hecho esto a veces con características que me fusioné, porque en JavaScript, puede mutar lo que quiera, cuando quiera, ya sea que documentado/definido esa propiedad o no.

Hubo cierta discusión sobre si TypeScript o simplemente JS moderno sería la respuesta. Me he dado cuenta de que no tener tipos o interfaces de objetos claras hace que el código base de Less a veces sea muy difícil de razonar de una manera que ninguna cantidad de documentación podría resolver o incluso JSDocs podría resolver.

Configuré la nueva canalización para permitir que TypeScript linting _si_ tiene tipos adecuados en JSDoc, pero usar JSDoc para escribir es mucho más detallado/visualmente ruidoso que TypeScript, y hay algunas características de escritura que TS simplemente no admite solo a través de anotaciones JSDoc . No existe una combinación de herramientas JSDoc / ESLint que pueda resolver algunas de estas cosas que TS le brinda de forma gratuita.

Entonces, supongo que todo lo que digo es que después de usar TypeScript significativamente en el último año, y después de haber pasado años en el código base de Less, diría que el 95% de la confusión/frustración/curva de aprendizaje de descubrir cómo funciona Less sería se han evitado si los objetos tenían tipos en tiempo de compilación aplicados. A menudo he pasado mucho tiempo en un depurador simplemente estableciendo puntos de interrupción y averiguando cuáles son las propiedades de un objeto _en realidad_, en lugar de cómo se define en un archivo.

Por ejemplo, hay una serie de características que tiene Less que, durante la evaluación, se basan en la propiedad $#$1$ Ruleset de un nodo paths . De este constructor , ¿puede decirme qué es la propiedad paths y qué forma tendrá? (Pista: no puedes, porque no está allí).

En TypeScript (con configuraciones comunes de tsconfig), esto no estaría permitido. Ni siquiera compilaría. Se vería obligado a especificar la forma de paths , y exactamente qué contendría, lo que a su vez brindaría documentación clara y específica (y sugerencias de código) a alguien que explore la base de código.

Entonces, supongo que en este punto, pasé de pensar: "TypeScript es algo a tener en cuenta" a sentir: "Si su proyecto público no está en TypeScript, tiene una gran deuda técnica". Nunca comenzaría ningún repositorio de código abierto sin él, porque inherentemente ayuda a resolver la capacidad de consumo y la mantenibilidad. Todavía necesita una documentación clara, pero al menos impone una codificación extremadamente clara y cohesiva.

Solo soy yo pensando a dónde ir desde aquí y formas de prevenir puntos débiles en el futuro.

_( Anexo : en caso de que no quede claro, estoy 100% no criticando el trabajo histórico de nadie en el código base de Less. Hay un montón de cosas que propuse, compré y fusioné en el código base que ahora Soy como, "Oof, desearía no haber hecho eso", o desearía haberlo hecho de manera diferente. Y ciertamente he agregado cosas que ahora me doy cuenta que podrían haber afectado negativamente la capacidad de mantenimiento. Todos hicieron lo mejor que pudieron)._

@mathew-dean
Configuré la nueva canalización para permitir el deslinzado de TypeScript si tiene los tipos adecuados en JSDoc, pero usar JSDoc para escribir es mucho más detallado/visualmente ruidoso que TypeScript, y hay algunas características de escritura que TS simplemente no admite a través de las anotaciones de JSDoc solas. . No existe una combinación de herramientas JSDoc / ESLint que pueda resolver algunas de estas cosas que TS le brinda de forma gratuita.

Realmente; Me encontré con el problema de que el soporte de JSDoc también era regular para la inferencia de tipos.
Afortunadamente, puede usar archivos de declaración .d.ts junto a archivos fuente .js , sin la necesidad de usar TypeScript completo y sin requerir el compilador.

Solía ​​ser mucho más difícil trabajar con archivos de declaración, pero las versiones modernas del compilador de TypeScript asociarán automáticamente un archivo .d.ts en paralelo con un archivo .js , siempre que ambos tengan el nombre. lo mismo.

Eso podría ser lo que estás buscando.

@rjgotten ¿Puede explicar un poco más (o vincular si conoce un buen recurso) cómo podría funcionar bien con el código base de Less? Como en, ¿cómo haces esto en un archivo por nivel de archivo? ¿Hay un archivo .js .d.ts módulo .js? ¿O los agrupas?

¿Cuáles son las ventajas de tener un archivo .d.ts frente a solo usar TypeScript en la fuente? ¿Por qué dedicar tiempo a crear archivos .d.ts en lugar de simplemente definir esos tipos en los archivos?

@rjgotten Estaba hablando con el desarrollador de Chevrotain hoy, y dice que lo que hace es desarrollar en TS _PERO_ en realidad administra un archivo api.d.ts como una preocupación separada. De esa manera, cualquier cambio de tipos en los archivos de origen (como los nodos de árbol) no cambia de forma transparente/invisible la API pública sin un cambio explícito del archivo de tipos de API.

Luego usa una prueba con una afirmación de que los tipos internos y los tipos de API pública coinciden -> https://github.com/SAP/chevrotain/blob/master/packages/chevrotain/test_integration/definitions/api_type_checking.ts#L1 - L2

La forma de Chevrotain es una buena manera de hacer cumplir que su API pública no cambie accidentalmente. Muy robusto, si cree que necesita ese nivel de protección. Pero también incurre en algunos gastos generales.

Con respecto al uso de archivos de declaración de .d.ts para contener tipos .js :
En realidad son ambos.

Si van uno al lado del otro, entonces cualquier IDE que esté respaldado por el compilador de TypeScript para sugerencias automáticas, pelusa, etc., detectará automáticamente las escrituras. Afaik _también_ si esos scripts con escrituras de lado a lado se importan desde node_modules , lo cual es bastante bueno.

También puede poner tipos en un solo (conjunto de) archivo(s) .d.ts como api.d.ts y luego usar JSDoc para importar los tipos declarados explícitamente. El soporte de JSDoc en TypeScript tiene un sabor especial de @typedef para eso con sintaxis de importación. P.ej

/**
 * <strong i="17">@typedef</strong> {import("../api.d.ts").MyType } MyType
 */

El uso de un solo archivo de tipificación incluido es una buena idea si tiene que llevar su paquete a través de un paso de transpilación antes de la distribución. En tal caso, lo que los usuarios realmente require() o import {} ya no serán los archivos fuente originales. Es decir, no se beneficiarían de tipeos uno al lado del otro.