Rome, ¡una cadena de herramientas moderna!

Hola a todos. Hoy hablaremos de Rome. ¿Has oído hablar de él? Bueno, si no lo has hecho, este es el momento.

Bueno, entonces, ciao a tutti. Hola a todos. Emmanuele, italiano. Viviendo en Irlanda durante 12 años, así que es mucho tiempo. Y estoy realmente apasionado por el código abierto. He estado trabajando en código abierto durante los últimos seis años en Webpack y ahora en Rome. Puedes llamarme Emma. No uses mi nombre completo. Es demasiado largo. Y nadie lo pronuncia correctamente. Y por supuesto soy el creador principal de Rome.

Ahora, Rome es una cadena de herramientas. Está destinado a reemplazar muchas herramientas que conoces. Pretier, Lint, Webpack, Lintstridge, y muchos más. Así que bastantes herramientas. Está construido en Rust. Y ha sido escrito por desarrolladores para vosotros, los desarrolladores.

Ahora, vamos a ello. ¿Por qué Rome? Bueno, tenemos dos cosas bastante famosas. Todos los caminos llevan a Rome. Y Rome no se construyó en un día. Así que esto tiene mucho. ¿Por qué moderno? Porque queremos proporcionar diagnósticos de alta calidad, es decir, errores significativos. Y debe funcionar en IDEs y CLIs, que son tus herramientas de trabajo diarias. ¿Y por qué una cadena de herramientas? Bueno, queremos proporcionar todas esas herramientas que te ayudan a mantener la salud de tu código base. Formateador, linter, bundler, generación de documentación, analizador en general. Así que tenemos muchas herramientas y nuestro objetivo es proporcionar la mayoría de ellas.

Sí, es mucho, pero llegaremos allí. Entonces, tomando todas estas definiciones, ahora veamos qué significa realmente. Entonces, en primer lugar, un archivo de configuración a través del modo. Este es un ejemplo de un proyecto web moderno. Como puedes ver, tenemos muchos archivos para cada herramienta, ptr, eslint, tailwind, tsconfig. Quiero decir, ya sabes a qué me refiero y hay mucho en marcha, ya sabes.

Tienes que mantener todos ellos por separado y queremos reducirlos todos y tener solo dos archivos, eventualmente también el log. Eso es a lo que aspiramos. Y es un ejemplo de tu archivo de configuración. Como puedes ver, desde un archivo puedes configurar todas las herramientas, todo allí, formateador, linter. También tenemos un esquema JSON, que consideramos realmente importante porque va a darte muchas ventajas, como, por ejemplo, auto-completado.

Entonces, esta es una captura de pantalla donde estoy tratando de escribir una regla dentro del grupo de estilo. Y como puedes ver, obtengo el auto-completado. Y también, obtengo una pequeña descripción que me dice de qué se trata la regla. Así que no necesitas ir al sitio web y entender de qué se trata la regla. tu IDE y, quiero decir, ve a DX. Lo bueno también es que nuestro esquema JSON se genera automáticamente a partir del código fuente code. Así que logramos documentar todo en nuestro código fuente code y difundir la documentation a través de diferentes canales, y el esquema JSON es uno de ellos. Así que este es un ejemplo, la línea con, verifica las descripciones. Y tenemos las mismas descripciones exactas en nuestro archivo RUST. Eso es un comentario de documentation. Es un comentario especial en la base de código RUST. Y es como un metadato que se adjunta a ese tipo, el lenguaje. Y con ese metadato, somos capaces de proporcionar la documentation para el esquema JSON. Y no somos un agregador de herramientas existentes. Un ejemplo de un agregador de herramientas existentes es create React app. Agrega muchas herramientas e intentan mejorarlas para nosotros. Pero es difícil porque todos tienen diferentes necesidades y configuraciones. Así que consume mucha energía y ralentiza tu entorno de trabajo. ¿Y por qué? Bueno, te diré por qué.

Entonces tienes tu aplicación. Vale. Genial. Tu código fuente code. Tienes todas estas herramientas alrededor de tus aplicaciones. Solo elegí algunas de ellas. Las más famosas. Pero seguramente hay aún más.

Lo que sucede es que cada herramienta tiene que analizar, pasar tu code, transformarlo, hacer operaciones. Y estas operaciones se repiten para cada herramienta. Digamos, por ejemplo, prettyer y ESLint. Necesitas analizarlo y hacer la operación. Lo mismo para ESLint. Así que esto es redundante.

Aunque estas herramientas pueden ser realmente geniales y lo son, hacen su trabajo. El problema es que no son conscientes entre sí. ¿Ves? Así que el hecho de que no sean conscientes entre sí también implica que la community necesita gastar mucho tiempo para compensar esta brecha. Un ejemplo, el plugin ESLint prettier. Así que un plugin que fue escrito para cerrar la brecha entre ESLint y prettier con el fin de suprimir algunas reglas de ESLint para que prettier pueda funcionar. Otros ejemplos, Vitt agrega, herramientas existentes como rollup, ESbuild, un observador de archivos. Y tienen que dedicar algún tiempo para sincronizarlos. Así que la community ha hecho mucho. Como el plugin Tertser web hub. Así que los nombras, hay un plugin para todo.

Con Rome en cambio, solo tienes tu aplicación. Tienes una herramienta, que es Rome. Y realiza la operación una vez. Así que tienes tu archivo. Este archivo se analiza una vez y generamos el CST o AST. En este caso generamos el CST.

Y esta estructura se comparte entonces entre todas las herramientas. Así que hacemos una copia, se la damos al formateador, hace su propio trabajo. Lo mismo para el linter. Su propio trabajo, y esa operación se realiza una vez.

Además, si tienes el linter y el formateador habilitados, y aplicas la code acción o la corrección de una regla de lint, esta code acción pasa por el formateador y aplica el formateador de la code acción basada en el archivo de configuración. Así que también son conscientes el uno del otro. Así que saben que coexisten. Esto no es así en este momento. Así que eso es lo que Rome pretende hacer.

Diagnóstico de alta calidad. Así que este es un buen ejemplo. ¿Alguna vez has visto este tipo de diagnóstico antes? Como token inesperado. ¿Qué es eso? Quiero decir, para ustedes, los desarrolladores de CISM, ya saben lo que es eso. Pero esto no es amigable para los principiantes. Como un principiante ve eso y como qué es YDR es inesperado. OK. Así que con Rome, queremos proporcionar errores mejores. Así que este es un ejemplo de un diagnóstico para el mismo fragmento. Así que tratamos de decir, escucha, en realidad encontramos un return, no un R. Y esperamos una expresión. Aunque expresar aún no es amigable para los principiantes, creo que es un paso adelante hacia una mejor experiencia de desarrollador. Así que ahora, este es un diagnóstico de Rome. Y quiero repasar la anatomía de un diagnóstico.

Así que este es otro ejemplo de diagnóstico proveniente de una regla de lint, que también sugiere code acción. Así que tenemos el nombre del archivo. Luego tenemos la posición donde ocurre el error. Luego tenemos una categoría, en este caso es el nombre de la regla. Y eso es en realidad un enlace. Así que puedes ir con tu ratón, puedes hacer clic en él, y te llevará a la documentación página y abrirá un navegador. Luego tenemos estas etiquetas o las llamamos tags que dan más metadatos al propio diagnóstico.

En este caso, este es un diagnóstico que puede ser corregido. Luego tenemos el mensaje y el color cambia en función del tipo de diagnóstico. En este caso, es una advertencia. No es un error porque es amarillo. Tenemos el marco de code donde resaltamos el error. Luego también tenemos una sección donde proporcionamos, intentamos proporcionar más información para dar un contexto al desarrollador de por qué pensamos que esto es realmente un error para esta regla.

Y luego finalmente obtenemos la acción de code. Así que esta es una corrección sugerida o mejor llamada correcciones inseguras, porque sabemos que JavaScript está lleno de efectos secundarios. Así que es bastante difícil proporcionar a veces acciones de code que sean seguras. Así que a veces tienes que optar por este tipo de correcciones de code.

Ahora les muestro el mismo diagnóstico en el IDE. Vale. Así que, como les dije antes, tienen que trabajar a través de CLI y LSP. Así que aquí tenemos el mismo fragmento de code. Esta es una captura de pantalla de VS Code que soporta LSP. Como pueden ver, obtenemos el mismo mensaje, vale, con el enlace real a la regla. No obtenemos la nota o descripción actual porque el LSP no soporta todo este tipo de información. Aunque tenemos... podemos proporcionar más acciones de code en el LSP porque esta es una sección interactiva. Así que en realidad proporcionamos dos acciones de code. La primera es la que vieron antes. Y la segunda, la supresión de la regla. Y si eliges la segunda, obtienes un comentario que suprime la regla. Y allí tenemos una explicación porque ROM requiere una explicación cuando quieres desactivar la regla. Creo que esta es una buena práctica. Así que en realidad decimos por qué desactivaste la regla. Como se considera como un comentario seguro. Como quieres usar el operador bang de la plaza del tiempo, que es blanco y seguro. Pero si sabes que es seguro, dejas el comentario para que tu colega vaya allí y sepa por qué desactivaste la regla para el operador bang. Necesita ser fácil de usar.

Así que elegimos solo dos comandos. Puedes usar ROM de esta manera. De hecho, puedes usar solo el segundo si quieres y realmente funciona. ¿Y por qué? Porque ROM tiene muy buenos valores predeterminados. Así que tenemos un conjunto de muy buenos valores predeterminados, opcionados. Vale. Eres libre de usar los valores predeterminados de ROM. Y no necesitas un archivo de configuración. Ni siquiera necesitas como puedes instalarlo en la extensión de VS Code y simplemente funcionará. Así que puedes usar la versión empaquetada de la extensión de VS Code y eso es todo. Así que también puedes usarlo en el CLI y funciona. También tenemos un CLI realmente potente, así que también queremos proporcionar tantas opciones como sea posible hasta cierto límite. Así que no necesitas instalarlo como una dependencia. Puedes usarlo en el CLI y funcionará. Y luego solo usa tu archivo de configuración. Puedes desactivar tus reglas de lint, cambiar el estilo de post, y así sucesivamente.

Así que este es un ejemplo de la sección de la aplicación del comando de formato. Y como puedes ver, intentamos proporcionar todas las opciones necesarias para personalizar tu experiencia de formato. Y si recuerdas, esa línea es la misma línea que te mostré antes al principio en el esquema JSON. Como puedes ver, eso también se genera automáticamente desde code. Así que nosotros, los desarrolladores, realmente escribimos la documentation en el código fuente y luego te la proporcionamos. Así que nos ahorra mucho tiempo. Uno de los beneficios del lenguaje RAST.

Ahora, te mostré algo que también quiero decirte, que ROM es bastante estable. Tiene muchas características. No tantas como esperábamos, pero el formateador es realmente estable. Está listo para producción. De hecho, está destinado a ser un reemplazo para Prettier. Todavía no soporta todas las opciones. Hay un poco de controversia en algunas de las opciones. Pero puedes participar en las discusiones de GitHub y podemos intentar proporcionar todas las demás opciones. Soportamos JavaScript y todos los super lenguajes, también JSON.

El linter tiene casi 150 reglas. No son tantas como en Lint, pero la community detrás de él todavía está trabajando en añadir nuevas reglas. También tenemos reglas de React 2. Todavía están en el grupo de guardería, así que este es en realidad un nuevo concepto que no existe en Lint, que son los grupos. Intentamos categorizar en grupos las reglas para que realmente conozcas el contexto de tu regla. También tienes que desactivar las reglas del grupo de estilo. Entre estos grupos, tenemos un grupo especial llamado guardería. Este es un concepto que tomamos prestado del ecosistema de Rust, que es un grupo de reglas que todavía están en desarrollo. Podrían estar rotas. También es como una red de seguridad para nosotros, los desarrolladores y mantenedores, para las reglas que están realmente rotas pero que son recomendadas por defecto y podemos degradarlas a la guardería porque es como si hubiera un falso positivo y es difícil de arreglar. Así que, simplemente las degradamos y no siguen la semantic versioning. Así que, también es bueno para nosotros, los desarrolladores. También tenemos ordenación de importaciones. Es un analizador, no el formateador, porque JavaScript es un lenguaje con efectos secundarios.

Entonces, necesitamos analizar tu code para mover tus importaciones. Se integra con VCS y, bueno, VLSP como te mostré antes, funciona de inmediato. Entonces, los diagnósticos funcionan de la misma manera que NCIL y LSP. Y ya hay algunos esfuerzos de la community en ese sentido. Entonces, hay un plugin para Nix, Helix, NeoVim.

Entonces, hay una radio community donde desarrollaron plugins para editores que soportan LSP. Todavía no IntelliJ, desafortunadamente, no soporta LSP. Entonces, quiero mostrarte ahora también algunas de las fortalezas de Rome. Entonces, algunas cosas que quizás no hayas visto, son un poco controvertidas y pero solo ten paciencia conmigo. Y quiero decir, creo que son buenas pero es para que tú juzgues.

Entonces, Rome tiene un analizador recuperable. Entonces, un analizador recuperable es un analizador que cuando encuentra un error de sintaxis no se detiene. Entonces, intenta reanudar el análisis correcto tanto como pueda, y luego intenta terminar el análisis real hasta el final del archivo. Debe ser resistente a errores porque este tipo de analizador debe funcionar en los IDs. Y el analizador que tenemos en los IDs, son los mejores analizadores en absoluto porque son resistentes a errores. Cuando el analizador de Rome ve un token o un carácter que no pertenece a esa posición, comienza a consumir esos tokens hasta que encuentra un token que realmente tiene sentido. No sé, una llave rizada que pertenece al cuerpo de una función. Allí, comienzan, el analizador comienza a reanudar el análisis correcto y todos esos tokens que fueron consumidos se fueron en este nodo falso.

Falso es en realidad un término que tomamos prestado del proyecto Roslyn. Roslyn es el compilador que impulsa .NET esencialmente. Entonces, tomamos prestados muchos conceptos de .NET, de este proyecto Roslyn. Es un gran proyecto si te interesan los compiladores. Entonces, ¿qué pasa con eso? Quiero decir, está bien, tenemos este analizador recuperable, ¿qué puedes hacer con eso? Bueno, podemos hacer muchas cosas de nicho, como podemos formatear code que tiene errores de sintaxis. Ahora, esto es bastante controvertido, porque muchos desarrolladores, yo incluido, usamos el formateador para entender si el code es realmente sintácticamente correcto o no. Entonces, esta es una característica optativa. También podemos enlazar el code roto. Entonces, creo que esto es bastante bueno. Está bien. Entonces, no necesitas tener un code perfecto para recibir diagnósticos. Y luego, también somos capaces de analizar el archivo de configuración y aplicar nuestros valores predeterminados solo para las secciones que están rotas.

Ahora, voy a mostrarte un pequeño video. Puede ser rápido, pero luego lo desglosaré y te mostraré lo que significa. Entonces, en este video, a la izquierda, hay un archivo de configuración que está roto. Entonces, hay un error de sintaxis. Y a la derecha, voy a intentar formatear algo de code basado en el estilo de code único. Teóricamente, para una herramienta que no tiene un analizador grabable, deberíamos ver algún error, como, oh, el archivo no funciona. Pero aquí, tenemos algún resultado. Ahora, quiero mostrarte lo que pasó.

Bien. Ahora, ese es el archivo de configuración. Entonces, tenemos una coma faltante allí antes del linter y también después del outro. Bien. Ahora, cuando ejecuté el comando, el primer diagnóstico fue sobre el análisis del archivo JSON. Entonces, tenemos el archivo, tenemos la categoría, que es el análisis. Y luego, un mensaje significativo que también intenta adivinar una posible sugerencia sobre cómo arreglar el archivo roto. No necesita ser correcto, pero como puedes ver, es un juego de adivinanzas con un analizador grabable. Luego, también tenemos un error semántico. Entonces, el archivo de configuración también, por ejemplo, en este caso no permite un conjunto de opciones como recomendado todo no puede ser ambos verdaderos. Entonces, durante la visualization del archivo de configuración, hubo un error. Ahora, lo bueno es que pudimos analizar como un nodo o una sección que estaba realmente rota. Bien. Entonces, logramos inspeccionar como un buen code que estaba dentro del mal code. Entonces, Romtex, mira, esto no es un error, pero Lisa aplicará mis propios valores predeterminados para ti. Y luego tenemos la acción de code del formateador que te muestra el estilo de code único. Entonces, si volvemos, agregamos estilo de code único y aquí es lo que tenemos. Entonces, logramos aplicar el formateador correcto. Ahora, Rome es rápido, ¿verdad? Entonces, esta es una captura de pantalla de nuestro benchmark. Entonces, en nuestro repositorio, tenemos una carpeta de benchmark donde puedes ejecutarla. Funciona con Docker y te lo dejo a ti, pero quiero mostrarte una pequeña demostración. Entonces, este es el repositorio de TypeScript y voy a intentar ahora ejecutar Pretier, bien, en el repositorio de TypeScript.

No tengo suficiente tiempo. Tengo que pararlo. Tarda demasiado. Ahora, voy a intentarlo con Rome. Voy a establecer el tamaño máximo del archivo porque hay un archivo de verificación que tiene dos megas y eso es todo. Como 644 archivos en pocos milisegundos. Gracias. Bueno, otro pequeño, uno rápido. Bueno, en realidad ya tenemos el resultado pero quiero mostrarte, hacerlo de nuevo. Entonces, AntDesign, si lo conoces, usa Roam, vale. Entonces, voy a ejecutar su comando. Quiero decir, en realidad funcionó como es tan rápido a veces que pienso que no funcionó pero no, funcionó. Entonces, ¿qué sigue para Roam? Entonces, el proyecto sigue activo. Esta es una community pequeña pero realmente enfocada y emocionada. Entonces, queremos dejar los archivos JSON, agregar nuevos idiomas y así, y establecer la base para el constructor. El bundler, más intros y así sucesivamente. Entonces, hay mucho en marcha. Poca información personal si quieres seguirme o a la community de Roam y gracias. Bueno, la primera pregunta que tenemos es, ¿puede convertir archivos de configuración existentes? ¿Puedes reutilizar reglas personalizadas de otras bibliotecas fácilmente? La cita es importante. Oh, no en este momento no. No puedes usar otras reglas de otros proyectos en este momento, no. ¿Qué sugerirías para alguien que tiene un montón de reglas configuradas en otro proyecto y luego querría usar Roam? Entonces, estamos trabajando en importar todas las reglas de ESLint que son recomendadas por la herramienta a Roam. Entonces, tenemos un plan de trabajo con un problema paraguas para intentar portar todas ellas. Y luego, como dije, hay algunos esfuerzos de la community para intentar portar también otras reglas, también de TypeScript, ESLint. Entonces, si quieres, simplemente inicia una discussion y podemos seguramente. Vale. Entonces, probablemente sea más fácil para alguien contribuir a Roam en lugar de intentar hacerlo ellos mismos dentro de su propio proyecto. Sí. Aunque es Rust, como, tenemos una muy buena documentation, sección contribuida, quiero decir, y también el idioma, podemos ayudar a todos