¿Por qué es CI tan malditamente lento?

Hola a todos. Mi nombre es Nicholas. Soy desarrollador de software en Rome Tools, y me gustaría hablar con todos ustedes sobre por qué su CI es tan increíblemente lento.

Todos hemos estado allí. Has subido tu último código a GitHub, tu servicio de CI está funcionando, y está tardando una eternidad. Esperas y esperas y esperas, solo para obtener tu resultado de vuelta 5, 10, incluso 20 minutos después. Es molesto, es disruptivo, es una pérdida de tu maldito tiempo. Normalmente, simplemente aceptamos esto como una verdad eterna. CI es lento. No creo que eso esté bien.

Tener que esperar por CI tiene un efecto directo y grave, tanto en tu productividad como en tus finanzas. Comencemos con un recurso que nos importa a todos. El tiempo del desarrollador. No sé ustedes, pero cuando encuentro una pérdida de tiempo como un CI lento, hago una de dos cosas. Holgazaneo, o comienzo otra tarea. Holgazanear es claramente un neto negativo. Claro, todos merecemos descansos, pero no cada vez que subimos algo de código. Nuestro CI no debería determinar cuándo trabajamos o no. Pero Nick, podrías simplemente comenzar otra tarea. Y sí, comenzar otra tarea parece tentador. Todos somos capaces multitareas. Resulta que no, no lo somos.

En el artículo, Task Interruption in Software Development Projects, los autores midieron el efecto del cambio de tareas en la productividad. No fue bueno. En particular, señalaron que las auto-interrupciones, básicamente cuando cambias de tarea a propósito, tienden a ser más disruptivas que las interrupciones externas y llevan a completar menos tareas. Con un CI lento, este flujo se interrumpe constantemente. Terminas cambiando entre los trabajos de CI y tu nueva tarea, perdiendo tu contexto de trabajo y por lo tanto tu eficacia y eficiencia. O peor, te concentras en tu nueva tarea, te olvidas de tu trabajo de CI, y solo recuerdas unas horas después que tu trabajo está hecho. Le envías un mensaje a tu revisor solo para darte cuenta de que se ha ido a casa. De repente, un PR rápido tarda dos días o más en fusionarse.

Aún peor es cuando tienes que depurar un flujo de trabajo de CI. Siempre que tengo que depurar uno, es tan terrible. Termino ajustando una configuración, esperando a que el trabajo se complete, distrayéndome, y solo viendo los resultados 15 minutos después. Un ciclo de desarrollo de 15 minutos no es aceptable en esta época. Pero no es solo el tiempo del desarrollador. Un CI lento significa más tiempo de cómputo, lo que, como cualquiera que haya mirado con asombro su factura de AWS sabe, significa más dinero.

Un ejemplo de esto es la instancia gratuita de GitLab de escritorio, que aloja un montón de proyectos de software libre, como Mesa, los controladores del kernel de Linux, y muchos otros. Experimentaron un gran período de crecimiento a finales de 2019 y principios de 2020. Sin embargo, sus gastos se dispararon en consecuencia, primero a $75,000 en 2019. Y luego se proyectó que alcanzarían $90,000 en 2020. Lograron reducir costos antes de quedarse sin dinero, pero aún así, para un proyecto de código abierto, eso es una cantidad enorme para gastar en CI. Hagámoslo mejor. Averigüemos por qué el CI es lento.

Para hacerlo, deberíamos mirar lo que hace un trabajo de CI. En su núcleo, hay dos tipos de trabajos de CI, trabajos estáticos y dinámicos. Los trabajos estáticos aplican herramientas de desarrollo, como un Linter, Bundler, Formatter, etc. a tu código sin ejecutar el código. Los trabajos dinámicos también pueden aplicar herramientas, pero tienen que ejecutar tu código. Nos vamos a centrar en los trabajos estáticos, pero muchas de estas lecciones se aplican también a los dinámicos. De todos modos, si tu trabajo de CI es lento, probablemente sea porque tus herramientas son lentas. Pero, ¿qué quiero decir exactamente con lento? Por supuesto, me refiero a que las herramientas son lentas en su tiempo de ejecución. Sin embargo, para CI, hay un segundo tipo de lentitud. Estas herramientas también son lentas en su tiempo de instalación. Tomemos ESLint. Es una gran herramienta. Sin embargo, como muchas herramientas en el ecosistema de JavaScript, tiene muchas dependencias. Esta no es una charla para avergonzar dependencias. Yo uso dependencias. Tú usas dependencias. Son una parte necesaria del desarrollo de software moderno.

Pero las dependencias sí tienen un impacto en tu CI. Es decir, tienes que instalarlas. Y a nadie le gusta esperar a que NPM o YARN hagan lo suyo. Y con JavaScript, siempre está la mayor dependencia de todas. Node. Tienes que descargar este runtime masivo solo para ejecutar tus otras dependencias. ¿Cuántas veces tiene que un servicio de CI iniciar un contenedor Docker con Node solo para ejecutar una herramienta como ESLint o webpack?

Y volviendo al tiempo de ejecución. ¿Por qué son lentas estas herramientas para ejecutarse? En Rome, pensamos mucho en esta pregunta. Primero y más obviamente, es porque la mayoría de las herramientas están escritas en JavaScript, y JavaScript no es el lenguaje ideal para herramientas de desarrollo. Usa mucha memoria, es difícil escribir código concurrente seguro, y requiere un runtime. La solución es, bueno, no escribir las herramientas en JavaScript. Usamos Rust. ESbuild usa Go. Bun usa Zig.

En nuestro caso, encontramos que Rust nos ha dado beneficios significativos. Primero escribimos Rome en TypeScript. Tuvimos que exprimir el rendimiento con JavaScript cuidadosamente optimizado y nuestros propios primitivas de bajo nivel. En Rust, obtuvimos un rendimiento muy bueno desde el principio. Segundo, porque Rust compila a un binario estático, ya no tenemos que instalar dependencias o un proceso de CI. Simplemente podemos descargar un binario. Y finalmente, hay un aspecto de las herramientas de JavaScript que creemos que está subestimado. Y ese es el problema del trabajo redundante. El ecosistema de herramientas de JavaScript es extremadamente fragmentado. Usamos diferentes herramientas para lint, formatear, empaquetar, y así sucesivamente. Cada herramienta por lo tanto necesita analizar y representar el JavaScript como un árbol de sintaxis. Si recuerdas tus compiladores, recordarás que los árboles de sintaxis ocupan una cantidad significativa de memoria. ¿Alguna vez te has preguntado por qué IntelliJ es lento? Está almacenando todos estos árboles de sintaxis. Sin mencionar que analizar implica I.O. que siempre viene con su propia sobrecarga. Por lo tanto, cada herramienta necesita hacer su trabajo.

Usa tres herramientas, tres veces el tiempo de análisis y tres veces la memoria. Con Roam, maneja linting, formateo, empaquetado, y así sucesivamente. Eso significa una etapa de análisis y un árbol de sintaxis. No hay computación desperdiciada ni memoria desperdiciada.

Con todo esto en mente, ¿cómo se ve nuestro trabajo ideal de CI? En el caso de trabajos estáticos, estos trabajos deberían operar como programas nativos sin un runtime de JavaScript involucrado. Realmente no hay razón para ejecutar Node o Docker para un linter o empaquetador. Pueden usarse como línea de comandos o como una API. En cuyo caso, la expectativa de rendimiento debería estar a la par con cualquier otra API REST. Lo llamas, obtienes un resultado en menos de un segundo. Por supuesto, para trabajos dinámicos, donde necesitamos ejecutar el código, aún podemos iniciar un runtime. Pero quizás podamos ceñirnos a entornos más ligeros. Algo como un AWS Lambda o CloudFlare worker podría ser suficiente.

Entonces, ¿dónde entra Roam en esto? Por ahora, estamos enfocados en entregar herramientas de JavaScript rápidas y nativas. Nuestro plan a largo plazo es ser la solución integral para todo JavaScript. Esperamos que en el futuro, estas herramientas sean el reemplazo para trabajos de CI estáticos. Pero, ¿por dónde empezamos? Por supuesto, no podríamos abordar todas las herramientas simultáneamente. Decidimos hacer algo de investigación, mirar repositorios de código abierto y ver qué era lento en su configuración de herramientas. Encontramos que el linting generalmente era bastante lento. Pero en particular, una regla destacó: prettier. Si no estás familiarizado, hay una regla de ES lint que verifica si tu código está formateado correctamente ejecutando prettier en tu código y viendo si algo cambia. En el caso de Babel, un compilador de JavaScript originalmente escrito por el fundador de Roam, Sebastian, la regla prettier de ES lint tarda más de seis segundos en completarse. Con Webpack, esta regla tarda cinco segundos. Podrías estar diciendo en este punto, ¿seis segundos? Eso no es tanto. Y estaría de acuerdo en abstracto. Pero en realidad, seis segundos es la diferencia entre ejecutar tu linter como un observador local y ejecutarlo en CI. Si toma seis segundos obtener tus resultados de lint, probablemente no vas a tener el linter integrado en tu flujo de desarrollo. Probablemente no querrás llamarlo a través de una API REST. En cambio, vas a depender de ejecutarlo como una tarea de CI. Vas a esperar más tiempo antes de ver posibles problemas en tu código. Con esta evidencia en mente, nos propusimos como misión mejorar el formateo.

No me malinterpreten. Me encanta prettier, pero puede volverse notablemente lento en archivos grandes. En particular, nos inspiramos en el formateador de Rust, que es súper rápido. Decidimos que queríamos un formateador del mismo nivel de rendimiento, pero para JavaScript. También queríamos un formateador que estuviera integrado en tu entorno de desarrollo.

Una característica particular de las herramientas de desarrollo que nos encanta se llama tolerancia a errores. Una herramienta es tolerante a errores si funciona incluso cuando tu código tiene errores, ya sean sintácticos o semánticos. Trabajamos mucho para hacer que el formateador sea tolerante a errores. De esa manera, aún puede hacer que tu código se vea bien sin importar qué.

Estamos muy emocionados de anunciar que nuestro formateador será lanzado para el 28 de marzo. Nos encantaría dar un adelanto del rendimiento de nuestro formateador. Primero, tenemos Dojo, un framework de front-end. Ejecutando el formateador en una biblioteca empaquetada, prettier tarda 75 milisegundos, lo cual no está mal, pero roam está en 10 milisegundos. Para Svelte, prettier llega hasta 750 milisegundos, casi un segundo, mientras que roam está en 200 milisegundos. Y finalmente, está el gigante que es checker.ts de TypeScript, con más de 44,000 líneas, o 2.64 megabytes. No sé si alguna vez has abierto este archivo en un editor, pero te diré ahora, ralentiza el mío hasta arrastrarse. Prettier tarda más de dos segundos en formatear este archivo. Nosotros lo hacemos en 335 milisegundos.

Pero eso es solo el comienzo. Nuestro próximo objetivo es winting. Como mencioné antes, winting es bastante lento en JavaScript. ESLint puede fácilmente tardar 15, 30 segundos en ejecutarse en una computadora de alta gama. Queremos ser una décima parte de eso. Winting también aprovechará el poder de nuestro análisis basado en Concrete Syntax Tree o CST. Una vez más, si estás familiarizado con los compiladores, puedes saber que los analizadores generalmente producen lo que se llama un Abstract Syntax Tree o AST. Los ASTs son geniales porque abstraen detalles innecesarios, como espacios en blanco o comentarios. Sin embargo, resulta que estos detalles supuestamente innecesarios son bastante importantes para otras herramientas de desarrollo. Específicamente, es realmente difícil hacer algo como analizar el código en un AST, modificar el AST, luego convertirlo de nuevo en código sin reorganizar completamente el código, creando así un gran diff en git. Con un CST, todo se preserva. Comentarios, espacios en blanco, todo.

Eso significa que convertir un CST de nuevo en código con solo un diff mínimo es extremadamente fácil, lo que a su vez abre un montón de potentes características de modificación de código. Estamos muy emocionados de demostrar las posibilidades del linting basado en CST. Nuestro linter saldrá para finales del segundo trimestre, y estamos muy emocionados de demostrar las posibilidades del linting basado en CST entre lenguajes.

Para recapitular, CI es lento porque nuestras herramientas son lentas, tanto en su tiempo de instalación como en su tiempo de ejecución. Son lentas porque usan lenguajes más lentos que dependen de runtimes y contenedores. Para hacer CI más rápido, necesitamos herramientas nativas y rápidas para JavaScript.

Si estos objetivos te parecen interesantes, vamos a estar contratando pronto. No dudes en contactarnos en Nicholas en RoamTools.com o a través de Twitter. Gracias.

Sí, una charla realmente genial y Nicholas, gracias por compartir eso con nosotros. De hecho, fue una charla bastante rápida para mí sobre lo lento que es CI, ¿verdad? Sí, no quería hacerte perder el tiempo. Pero fue buena. Pero has desglosado mucho ahí, así que gran charla. Vamos a ver nuestros resultados de Slido. Estoy realmente intrigado de ver lo que la gente está pensando. ¿Cuál es su herramienta más lenta y molesta? Vamos a comprobar eso juntos. Entonces Bundler, el 50% dice Bundler. OK, eso es interesante. Pero en segundo lugar, tenemos IDE. Así que si quieres compartir en el chat qué IDEs estás usando, nos encantaría saber cuáles estás usando y encuentras bastante lentos. Y a menos que eso sea como etcd allí, me encantaría desglosar también el etal o et cetera para saber qué está en tercer lugar. ¿Qué está en tercer lugar, así que cuéntanos qué otras herramientas crees que no hicieron la lista. Nos encantaría saber sobre esas. Y sí, escuchemos lo que la gente tenía que preguntar, Nicholas. Comencemos con algunas de las preguntas y respuestas.

Muy bien, genial. Entonces, comencemos con ¿qué hay de las pruebas? ¿No hay problemas de rendimiento inherentes con las pruebas? Sí. Estoy de acuerdo con eso. Diría que las pruebas son, posiblemente, lo que hace que CI sea lo más lento, y hay un límite inherente a las pruebas siendo solo código que tienes que ejecutar. Pero creo que, ya sabes, hay soluciones potenciales en esta área.

Por ejemplo, puedes hacer que la sobrecarga de tiempo de ejecución sea mucho menor. Puedes usar algo como una curva de trabajo optimizada para tener una aceleración rápida y un inicio rápido. También puedes investigar posibles optimizaciones dentro de JavaScript. Como tal vez puedas hacer que JavaScript se ejecute más rápido. Tal vez puedas encontrar formas de precompilar el JavaScript. Creo que, ya sabes, lo hemos estado tratando como una caja negra. Pero creo que hay posibilidades allí que realmente podemos usar para hacer que CI sea un poco más rápido y un poco más receptivo.

Sí, en el frente de las pruebas, estoy de acuerdo. Creo que hay mucho que se puede hacer allí para optimizar. Entonces, en las pruebas, quiero decir, ¿cuáles son las otras tareas pesadas en ese proceso? Solo me pregunto qué más, ya sabes?

Sí, entonces diría pruebas. El benchmarking es otro clásico porque, de nuevo, con el benchmarking, ya sabes, tienes que ejecutar el código y tienes que mantenerlo. A menudo tienes que ejecutar el código varias veces. Sabes, muchos marcos de benchmarking modernos hacen análisis estadísticos. Y por eso tienen que ejecutarlo una cantidad estadísticamente significativa de veces. Y entonces, ya sabes, si no hay una gran solución porque, ya sabes, es, de nuevo, benchmarking. Pero creo que, ya sabes, hay algunas técnicas que podemos tomar de grandes empresas. Por ejemplo, sé que en Facebook, solo ejecutan benchmarks y pruebas relevantes para el commit. Así que no ejecutan toda la suite de pruebas porque obviamente Facebook está operando a la escala de Facebook y no puedes ejecutar todas las pruebas que hay. Así que creo que realmente... Creo que estamos realmente emocionados de ver cómo otras personas abordan, cómo otras personas abordan este problema. Y también estamos realmente emocionados de mostrar a la gente nuestras soluciones a este problema.

Genial. Entonces Sissy Miller pregunta, viniendo del mundo de PHP, Pest PHP está revolucionando el mundo de las pruebas allí y está haciendo que las pruebas sean masivamente más rápidas. Pero le gustaría preguntar, o no, él o ella, no lo sé. ¿Estarías de acuerdo en que parte de la lentitud de CI puede ser evitada con un código más limpio? Yo estaría de acuerdo. Quiero decir, ciertamente, por supuesto. Creo que, ya sabes, hay tanto código más limpio en las herramientas como también código más limpio en tu código normal. Quiero decir, obviamente si estás ejecutando el código, es... Quieres que tu código sea rápido y no lento. Y diría, desde mi perspectiva, como alguien que escribe herramientas, creo que eso es algo que ha sido descuidado en el mundo de las herramientas es el rendimiento.

Y, ya sabes, me gustaría dar un reconocimiento a muchas personas que están escribiendo herramientas que piensan en el rendimiento con mucho cuidado, como los autores de ESBuild, y los autores de SWC. Nosotros en Roam, ponemos mucho esfuerzo en eso. Y de hecho, yo realmente... Los benchmarks que les mostré en la charla están realmente significativamente desactualizados. Hemos estado haciendo mucha optimización de rendimiento desde entonces, y diría que nuestros números son quizás un 20% o 30% mejores que eso, lo cual es un trabajo realmente fantástico. Y estoy muy emocionado de mostrar eso a la gente. Creo que, ya sabes- Eso es realmente genial. Sí, siempre hay más que puedes hacer. Hay más rendimiento que puedes exprimir. Así que sí.

Solo, supongo, compartir un poco. ¿Qué tipo de mejoras de rendimiento has implementado en Roam? Solo de memoria. Así que, por ejemplo, una gran cosa que siempre tienes que hacer es analizar el código. Y el análisis es notoriamente lento por varias razones. Primero, tienes que leer el código desde I.O. Y segundo, tienes que crear esta gran estructura de datos. Así que hemos estado trabajando mucho para básicamente asegurarnos de que cuando analizas, estás haciendo la mínima cantidad de trabajo porque a menudo puedes analizar algo y luego darte cuenta de que es un constructo sintáctico diferente. Así que, por ejemplo, puedes estar, tu analizador podría estar analizando algún código y darse cuenta, oh, espera un minuto, no es una expresión JSX, es una aserción de tipo TypeScript porque resulta que estas dos cosas se ven muy, muy similares. Y hemos estado poniendo mucho trabajo en ese proceso donde el analizador se da cuenta de que es algo diferente de lo esperado. Tiene que retroceder. Estamos tratando de hacer eso cada vez menos para que el análisis sea mucho, mucho más rápido.

También estamos poniendo mucho trabajo en el formateo, asegurándonos de que el formateador esté haciendo solo lo mínimo necesario. Y realmente no está haciendo trabajo redundante moviendo texto y reorganizando el código.

Bien, veo eso, gente, solo voy a animar a la gente a primero, recordarles sobre el Slido, si quieren decirnos qué otras herramientas encuentran molestas y lentas, nos encantaría escuchar del 11% de ustedes. Y también qué IDEs están usando. Nos encantaría saber eso. Y también si responden a tiempo, tal vez Nicholas pueda darnos sus pensamientos sobre por qué cree que esas son herramientas específicamente lentas. Pero, quiero decir, supongo que desde mi perspectiva personal, me gustaría decir que no encuentro mi CI muy lento. Entonces, ¿por qué es esto algo que debería importar? ¿Por qué debería preocuparme por esto? Ese es un muy buen punto. Y, ya sabes, me alegra que tu CI no sea lento. Me alegra que, ya sabes, no estés esperando como algunas otras personas. Diría que creo que las Herramientas Rápidas son universalmente algo bueno, incluso si no es para tu CI. Creo que, ya sabes, realmente, de nuevo tenemos que recordar que no todos están usando, ya sabes, una computadora súper moderna. Como dije en la charla, ya sabes, nosotros, como a menudo como desarrolladores en, ya sabes, empresas obtenemos, ya sabes, hardware moderno, como, ya sabes, bastante a menudo. Pero como, ya sabes, hay muchas personas por ahí que están comenzando, o tal vez en empresas que no tienen un presupuesto donde están usando, ya sabes, hardware más lento y tenemos que acomodarlos. Creo que realmente no es justo escribir código que solo funciona en, ya sabes, un MacBook Pro nuevo. Tiene sentido. Eso es, ya sabes, sí. Sí, puedo apreciar eso, obviamente. Así que eso fue hablado desde muy dentro de Turbulent.

Eso fue una de esas cosas, y yo estaba como, está bien. Sí, quiero decir, yo también he sido culpable de eso. Sabes, ejecuto el código y pienso, oh, es divertido rápido, pero, ya sabes, creo, olvido qué empresa es, pero tenían la costumbre de básicamente ralentizar su conexión a internet, como básicamente estrangularla con el propósito expreso de acomodar a personas que están en, como, una conexión 3G o incluso 2G, porque creo que eso es una lección realmente, ya sabes, importante para dar a los desarrolladores.

Sí, eso es muy cierto. Dainy pregunta, ¿puedes compartir algunos detalles sobre el Linter? ¿Cómo se comparará con ESLint en términos de reglas, plugins, otros factores? Sí, estoy realmente emocionado por este porque el Linting es algo que, ya sabes, ha sido lento por un tiempo. Y obviamente, ESLint es un proyecto fantástico, y tienen muchas reglas, y no voy a salir y decir que vamos a capturar todas estas reglas de una vez, porque, ya sabes, como todos siempre me dicen todo el tiempo, Roma no se construyó en un día. Así que diría que en lo que nos estamos enfocando es cuáles son las reglas que son las más lentas en ESLint, cuáles son las cosas que realmente lo hacen doloroso, y luego vamos a construir un winter para esas reglas específicas. Y luego, ya sabes, la idea tal vez es que entonces puedas ejecutar nuestro winter, obtener retroalimentación rápida para ciertas cosas. Y si quieres una configuración de Linting completa, aún puedes ejecutar ESLint, y aún puedes obtener toda la retroalimentación de ESLint, pero obtendrás la retroalimentación rápida primero.

Eso es genial. Entonces Nicholas, alguien, J. Reid está diciendo, Nicholas mencionó que algunas de las diversas herramientas en el ecosistema JS, ecosistema JavaScript, cada una tiene que construir sus propios ASTs. Disculpas, no sé qué significa ASTs, para hacer lo suyo. ¿Alguien sabe si hay alguna colaboración sucediendo entre algunas de las herramientas más populares con el objetivo de compartir un único AST? Solo dime qué es un AST rápidamente. Árbol de Sintaxis Abstracta. Así que es lo que el analizador produce. Sí, y hasta donde yo sé, no creo que haya. Quiero decir, podría estar equivocado, y estoy feliz de que me demuestren que estoy equivocado en esto, porque creo que sería un gran proyecto. Una cosa que creo que es realmente inspiradora es el Proyecto TreeSitter, que es un analizador que básicamente puede analizar múltiples lenguajes diferentes, prácticamente cualquier lenguaje que puedas pensar hay un analizador TreeSitter para, incluyendo JavaScript. Y ese es un gran ejemplo de básicamente alguien escribiendo un analizador realmente genial, que luego mucha gente puede usar. Creo que no estoy realmente seguro si hay alguna manera de compartir el AST actualmente. Quiero decir, obviamente hay algunos problemas con si una herramienta cambia el AST, entonces las otras herramientas realmente no pueden usar el mismo AST. Así que es un poco complicado. Y no estoy seguro de que eso necesariamente funcionaría sin algunos cambios serios. Genial. Gracias. Eso es un... esa fue una muy buena respuesta. Cece Miller hace otra pregunta. ¿Has mirado la interpretación de código por IA como GitHub go pilot, GitHub copilot? Quizás esto podría llevarlo a otro nivel.

Personalmente, he jugado con ellos. También soy un gran fan de Tab 9 y Copilot. Creo que son proyectos realmente geniales. Sí, Tab 9 es un proyecto fantástico. No diría que esa es necesariamente la dirección que estamos tomando en Roam en este momento. Creo que definitivamente es algo que estamos abiertos a explorar en el futuro. Quiero decir, creo que, ya sabes, ML más código es un área realmente fascinante que definitivamente se desarrollará más en los próximos años.

Creo que una cosa que hemos investigado y he estado considerando es quizás usar aprendizaje automático para la recuperación de errores del analizador. Así que como mencioné, en la charla, una gran cosa sobre nuestro analizador es que tiene una muy buena recuperación de errores. Básicamente, puede notar cuando hay un error y básicamente intentar adivinar qué quisiste decir con él. Y ahora mismo hacemos eso con algunas heurísticas, pero creo que en el futuro, podría ser una oportunidad realmente interesante para el aprendizaje automático donde básicamente puedes usar conjuntos de datos de código incorrecto para estimar cuál es el código previsto y luego ofrecer una corrección o simplemente un mejor análisis semántico.

Sí, eso tiene sentido. Forlex, no sé si es Forlex o si es Leap como Alex, pero pregunta qué pasa con todas esas reglas personalizadas de linter que vienen con otras bibliotecas gratis como lint, ¿cómo apoyarás esto? Esa es una muy buena pregunta. Voy a ser honesto, todavía estamos tratando de resolver eso nosotros mismos. Creo que, ya sabes, de nuevo, tenemos esta idea de como, algo así como R12 siendo como el explorador que sale adelante. Y como, ya sabes, si nuestras reglas son incorrectas deberías corregir esas primero. Y luego si nuestras reglas son todas, ya sabes, válidas y el código es correcto para estas reglas entonces puedes ejecutar eswint y obtener la finalización completa.

No, ya sabes, de nuevo, creo que vamos a hacer nuestro mejor esfuerzo para ofrecer una, ya sabes, amplia variedad de reglas y vamos a seguir añadiendo más pero la realidad es que eswint, ya sabes, hace un trabajo maravilloso y también es una comunidad muy floreciente. Y, ya sabes, tenemos que reconocer eso. Sí. Impresionante. Estás recibiendo comentarios realmente geniales aquí. Solo voy a decirte que lo que la comunidad piensa realmente buenas ideas de tu compañero en la sala de discusión, en la sala de construcción, Ante Tomić. Realmente buenas ideas. Tiene curiosidad por Rome, quiere echarle un vistazo y muchos comentarios realmente geniales sobre la charla.