Rome, ¡una cadena de herramientas moderna!

Rate this content
Bookmark

Los proyectos modernos de JavaScript vienen en muchas formas: sitios web, aplicaciones web, aplicaciones de escritorio, aplicaciones móviles y más. Para la mayoría de ellos, el denominador común es la deuda técnica que proviene de la configuración de herramientas: empaquetadores, suite de pruebas, análisis de código, documentación, etc. Quiero presentarte Rome, una cadena de herramientas que aspira a ser una herramienta todo en uno para la web, con una sola herramienta puedes mantener la salud de todos tus proyectos!

Emanuele Stoppa
Emanuele Stoppa
31 min
01 Jun, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Rome es una cadena de herramientas construida en Rust que tiene como objetivo reemplazar múltiples herramientas y proporcionar diagnósticos de alta calidad para el mantenimiento del código. Simplifica las interacciones de las herramientas al realizar todas las operaciones una vez, generando una estructura compartida para todas las herramientas. Rome ofrece una experiencia de formato personalizable con un formateador estable y un linter con más de 150 reglas. Se integra con VCS y VLSP, admite el análisis de errores resistente y tiene planes emocionantes para el futuro, incluida la capacidad de crear complementos de JavaScript. Rome aspira a ser una cadena de herramientas de primera categoría y da la bienvenida a las aportaciones de la comunidad para mejorar su trabajo.

Available in English

1. Introducción a Rome

Short description:

Hoy hablaremos de Rome. Rome es una cadena de herramientas destinada a reemplazar muchas herramientas. Está construido en Rust y proporciona diagnósticos de alta calidad. Funciona en IDEs y CLIs. Rome tiene como objetivo proporcionar todas las herramientas para mantener la salud de tu base de código.

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.

2. Configuración y Esquema JSON

Short description:

Sí, es mucho, pero llegaremos allí. Este es un ejemplo de un proyecto web moderno. Tienes que mantener por separado todos los archivos para cada herramienta, pero nuestro objetivo es reducirlos a solo dos archivos. Nuestro esquema JSON se genera automáticamente a partir del código fuente, proporcionando documentación y auto-completado. No somos un agregador de herramientas existentes como create React app, que puede ralentizar tu entorno de trabajo.

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é.

3. Interacciones de Herramientas y Rome

Short description:

Cada herramienta analiza, transforma y opera en tu código individualmente. No son conscientes entre sí, requiriendo plugins y esfuerzos de sincronización. Rome simplifica esto al proporcionar una única herramienta que realiza todas las operaciones una vez, generando el CST o AST.

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.

4. Compartiendo Estructura y Anatomía de Diagnóstico

Short description:

Y esta estructura se comparte entre todas las herramientas. El formateador y el linter tienen sus propias tareas, y son conscientes el uno del otro. Rome tiene como objetivo proporcionar diagnósticos de alta calidad y errores mejores para una mejor experiencia de desarrollador. La anatomía de un diagnóstico incluye el nombre del archivo, la posición del error, la categoría y las etiquetas.

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.

5. Corrección de Diagnóstico e Integración con IDE

Short description:

En este caso, tenemos un diagnóstico que puede ser corregido. El mensaje y el color indican que es una advertencia. Proporcionamos un marco de código para resaltar el error e información adicional para dar contexto. Las acciones de código son correcciones sugeridas, pero pueden ser inseguras. En el IDE, vemos el mismo diagnóstico con un enlace a la regla. LSP admite acciones de código, incluyendo la supresión de la regla con una explicación.

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.

6. Comandos y Configuración de ROM

Short description:

ROM proporciona dos comandos con muy buenos valores predeterminados, permitiéndote usarlo sin un archivo de configuración. Funciona sin problemas con la extensión de VS Code y CLI, proporcionando un CLI potente con muchas opciones. Puedes personalizar tu experiencia de formato utilizando tu archivo de configuración.

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.

7. Sección de la Aplicación del Comando de Formato

Short description:

Este es un ejemplo de la sección de la aplicación del comando de formato. ROM proporciona opciones para personalizar tu experiencia de formato. El formateador es estable y está destinado a reemplazar a Prettier. El linter tiene casi 150 reglas y soporta React. Las reglas se categorizan en grupos, incluyendo un grupo de guardería para reglas en desarrollo. La ordenación de importaciones está disponible como analizador.

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.

8. Fortalezas de Rome y Analizador Recuperable

Short description:

Rome se integra con VCS y VLSP, apoyando diagnósticos similares a NCIL y LSP. Hay esfuerzos de la comunidad y plugins disponibles para varios editores, excepto IntelliJ. El analizador recuperable de Rome permite un análisis resistente a errores, continuando el análisis incluso en presencia de errores de sintaxis. Toma conceptos del proyecto Roslyn y permite características de nicho como formatear código con errores de sintaxis y enlazar código roto. Rome puede analizar archivos de configuración y aplicar valores predeterminados solo a las secciones rotas.

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.

9. Analizando un Archivo de Configuración Roto

Short description:

Ahora, voy a mostrarte un pequeño video donde tenemos un archivo de configuración roto con errores de sintaxis y semánticos. A pesar de no tener un analizador grabable, Rome es capaz de proporcionar diagnósticos significativos y sugerencias para arreglar el archivo roto. Rome puede analizar e inspeccionar secciones de código incluso dentro de un archivo roto. Además, Rome es rápido, como se demostró en nuestro benchmark.

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.

10. Uso de Rome y Planes Futuros

Short description:

No tengo suficiente tiempo para explicar, pero probé Rome y es rápido. El proyecto sigue activo con planes emocionantes. Todavía no puedes convertir archivos de configuración existentes o reutilizar reglas personalizadas de otras bibliotecas. Estamos trabajando en ello y hay esfuerzos de la comunidad. Contribuir a Roam es más fácil que hacerlo tú mismo.

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

11. Futuro de las Herramientas Roam y Comparación con Otras Herramientas

Short description:

El futuro de las herramientas Roam incluye la capacidad de crear plugins de JavaScript. La comunidad está pidiendo esta característica, y tenemos una prueba de concepto creada por un ex colega. Queremos establecer las bases de las secciones más importantes y desafiantes. Al comparar RUM con otras herramientas como TurboPack y SWC, aspiramos a ser una cadena de herramientas que te permita usar tu CLI y mantener tu código fuente en diferentes ángulos.

para abordar el problema y el lenguaje. Sí. Sí. Genial. Muy bien. Siguiente pregunta. Y ya has tocado un poco este tema, pero nos encantaría saber, ¿cómo ves el futuro de las herramientas Roam? ¿Hacia dónde te gustaría que se dirigiera? Mencionaste, más o menos, lo que viene a continuación, pero quizás incluso, como, más hacia el futuro. Bueno, esa es una buena pregunta. Entonces, lo que realmente nos gustaría hacer, también es ser capaces de crear plugins de JavaScript. Esto es algo que la community está pidiendo mucho. Tenemos preguntas aquí sobre plugins. Entonces, esto es genial. Sí. Sí. Pero primero, nos gustaría intentar establecer las bases de las secciones más importantes las más desafiantes, pero creo que también las más importantes. También tenemos, como, una prueba de concepto para crear un plugin de JavaScript creado por un ex colega mío. Hay una rama allí que fue creada. Todavía no la he mirado, pero... Está allí. Sabes que está allí. Y funciona. Vale, paso. Genial. Muy bien. La siguiente. ¿Cómo se compara RUM con otras herramientas como TurboPack, SWC, BUN, similares, etcétera? Eso es un montón de herramientas. ¿Cómo se compara con otras herramientas? Sí. En nuestro ecosistema. SWC, por lo que entendí, quiere ser como un reemplazo de BUBBLE. Vale. Nosotros también queremos ser eso, pero somos una cadena de herramientas. Así que quieres usar tu CLI

12. La Ambición de ROAM y las Suposiciones Diagnósticas

Short description:

ROAM aspira a ser una cadena de herramientas, proporcionando un trabajo más ambicioso y de alta calidad en comparación con SWC y TurboPack. Aunque ROAM aún no tiene TypeScript ESLint con verificación de tipos, están intentando usar TypeScript para recopilar información de tipado y convertirla en una estructura de datos legible en Rust. Al decidir qué diagnósticos proporcionar más contexto, ROAM va con suposiciones y tiene como objetivo dar buenas sugerencias, tomando descripciones de herramientas existentes y dándoles crédito. Son de mente abierta y dan la bienvenida a las aportaciones de la comunidad para mejorar su trabajo.

y mantener tu code en todos los ángulos diferentes. Entonces, para Martin, esto es algo que SWC no tiene. Y también TurboPack. TurboPack está diseñado para hacer un trabajo muy bien, y eso es todo. ROAM quiere ser algo diferente, una cadena de herramientas. Así que es más ambicioso, va a haber más trabajo, y también la calidad de este trabajo tiene que ser de primera categoría. Pero eso tiene sentido. El alcance es completamente diferente de esa manera. Sí. Muy bien. Entonces, ¿existe algo como TypeScript ESLint con verificación de tipos para ROAM? Todavía no. ¿No es bueno? ¿Todavía no? ¿Eso significa que está por venir? Así que queríamos intentar usar realmente TypeScript para recopilar toda la información de tipado y luego convertirla en una estructura de data que pueda ser leída en Rust, y luego intentar usar estos metadatos para proporcionar reglas significativas. Porque un verificador de tipos es bastante difícil, especialmente TypeScript, porque aunque es un verificador de tipos, sigue siendo un lenguaje de tipado dinámico, por lo que es muy, muy difícil de implementar. Ese es nuestro primer intento, así que intentamos usar la herramienta existente y luego tomar prestado. Eso tiene sentido. Muy bien. Esta es una de las que me emocionaba. Entonces, ¿cómo decidiste qué diagnósticos proporcionar más contexto? ¿Te basaste en suposiciones, tal vez en la investigación del usuario? Sí, vamos con suposiciones, en realidad. Así que tenemos algunos pilares en nuestra página de documentation donde intentamos decir, está bien, los errores, necesitan tener el máximo contexto posible. Tienen que usar palabras amigables para los principiantes. Así que intentamos ser conscientes e intentamos asumir que el usuario es en realidad un principiante. Y luego, en base a eso, intentamos dar buenas suggestions. Pero, sí, vamos con suposiciones. Y en caso de que tomemos prestado y tratemos de replicar una regla de las herramientas existentes, en realidad tomamos prestada su descripción. La hacemos un poco diferente, pero proporcionamos los créditos y la fuente de la regla, porque ellos inventaron la regla, se merecen un crédito. Así que esas son las suposiciones reales que hacemos cuando intentamos proporcionar diagnósticos. Así que... Sí, eso tiene sentido. Trabajo en documentation para obtener esa pregunta todo el tiempo. Como, más o menos, si vas a poner ese esfuerzo, ¿cómo sabes incluso por dónde empezar? Pero creo que tal vez lidiando con algunos de los problemas que obviamente enfrentas, como el uso de estas otras herramientas, ¿dónde podría alguien que está entrando en el proyecto necesitar esa suposición? Como tuvimos un caso en el que teníamos el rol que estaba bajo una sección, y luego la community vino a ayudar. Y con la discussion en realidad cambiamos la redacción y también la categoría. Así que somos de mente abierta. No estamos cerrados. Queremos que la community nos ayude si estamos haciendo algo mal. Así que queremos arreglarlo. Esa es una gran nota para terminar. Muchas gracias, Ema. Por favor, denle otra ronda de aplausos.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

The Future of Performance Tooling
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
Server Components with Bun
Node Congress 2023Node Congress 2023
7 min
Server Components with Bun
Top Content
An early look at using server components via Bun’s new bundler, with and without React.
Improving Developer Happiness with AI
React Summit 2023React Summit 2023
29 min
Improving Developer Happiness with AI
GitHub Copilot is an AI pair programmer that can help you write code faster and spend less time writing repetitive code.This session will cover some interesting use cases for Copilot that could shine a light on its possibilities. This ranges from prompting Copilot to suggest a function based on a comment, learning how to use a new framework, tackling a security or accessibility bug, better documenting your code, translating  code from one language to another, etc.Agenda:
Introduction to CoPilot
- What is Copilot
- How can you use it
- How it can help you write code faster
- Copilot Labs experimental features I will pick examples from the React ecosystem and show how we can fix Security Vulnerabilities and Accessibility issues in some components.
Static Analysis in JavaScript: What’s Easy and What’s Hard
JSNation 2023JSNation 2023
23 min
Static Analysis in JavaScript: What’s Easy and What’s Hard
We are all using static analysis tools like ESLint every day to ensure the better quality of our code. How does it work, and what is tricky about JavaScript, making writing a proper rule often not trivial?
How I Automated Code Changes for 100 Repositories: Getting Started With Codemods
React Day Berlin 2022React Day Berlin 2022
28 min
How I Automated Code Changes for 100 Repositories: Getting Started With Codemods

Workshops on related topic

Solve 100% Of Your Errors: How to Root Cause Issues Faster With Session Replay
JSNation 2023JSNation 2023
44 min
Solve 100% Of Your Errors: How to Root Cause Issues Faster With Session Replay
WorkshopFree
Ryan Albrecht
Ryan Albrecht
You know that annoying bug? The one that doesn’t show up locally? And no matter how many times you try to recreate the environment you can’t reproduce it? You’ve gone through the breadcrumbs, read through the stack trace, and are now playing detective to piece together support tickets to make sure it’s real.
Join Sentry developer Ryan Albrecht in this talk to learn how developers can use Session Replay - a tool that provides video-like reproductions of user interactions - to identify, reproduce, and resolve errors and performance issues faster (without rolling your head on your keyboard).