Rome, una herramienta 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 configurar herramientas: empaquetadores, suites de pruebas, análisis de código, documentación, etc. Quiero presentarte Rome, una herramienta que tiene como objetivo ser una herramienta todo en uno para la web, con una sola herramienta puedes mantener la salud de todos tus proyectos.

31 min
01 Jun, 2023

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 de 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 análisis de errores resistentes y tiene planes emocionantes para el futuro, incluida la capacidad de crear complementos de JavaScript. Rome tiene como objetivo ser una cadena de herramientas de primera categoría y da la bienvenida a la contribución 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 su base de código.

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

Ok, entonces, ciao a tutti. Hola a todos. Emmanuele, italiano. Llevo viviendo en Irlanda durante 12 años, así que es mucho tiempo. Y soy 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, hago el contenedor principal de Rome.

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

Ahora, profundicemos en ello. ¿Por qué Rome? Bueno, tenemos dos cosas bastante famosas. Todos los caminos llevan a Roma. Y Roma no se construyó en un día. Así que esto tiene mucho. ¿Por qué moderno? Porque queremos proporcionar diagnósticos de alta calidad, errores significativos. Y debe funcionar en IDEs y CLIs, que son las herramientas de su trabajo diario. ¿Y por qué una cadena de herramientas? Bueno, queremos proporcionar todas esas herramientas que le ayuden a mantener la salud de su código base. Formateador, linter, generación de bundler, documentation, 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. Debes 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 autocompletado. 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, veamos qué significa realmente. Primero que nada, 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, sabes a lo que me refiero y hay mucho sucediendo, ya sabes.

Debes mantenerlos por separado y queremos reducirlos a solo dos archivos, eventualmente también el registro. Eso es lo que pretendemos. Y es un ejemplo de tu archivo de configuración. Como puedes ver, desde un archivo puedes configurar todas las herramientas, todas ellas, formateador, linter. También tenemos un esquema JSON, que consideramos muy importante porque te va a dar muchas ventajas, como por ejemplo, autocompletado.

Esta es una captura de pantalla donde intento escribir una regla dentro del grupo de estilos. Y como puedes ver, obtengo el autocompletado. Y también obtengo una pequeña descripción que me dice de qué trata la regla. Así que no necesitas ir al sitio web y entender de qué trata la regla. tu IDE y, quiero decir, ir a DX. Lo bueno también es que nuestro esquema JSON se genera automáticamente a partir del código fuente. Así que logramos documentar todo en nuestro código fuente y difundir la documentación 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 esas descripciones. Y tenemos las mismas descripciones exactas en nuestro archivo RUST. Ese es un comentario de documentación. Es un comentario especial en la base de código de RUST. Y es como un metadato que se adjunta a ese tipo, el lenguaje. Y con ese metadato, podemos proporcionar la documentación 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 y tratan de mejorarlas para nosotros. Pero es difícil porque todos tienen diferentes necesidades y configuraciones. Así que requiere 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 de forma individual. No están conscientes entre sí, lo que requiere complementos y esfuerzos de sincronización. Rome simplifica esto al proporcionar una sola herramienta que realiza todas las operaciones una vez, generando el CST o AST.

Así que tienes tu aplicación. De acuerdo. Genial. Tu código fuente. 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 solo tiene que analizar, pasar tu código, transformarlo, realizar operaciones. Y estas operaciones se repiten para cada herramienta. Digamos, por ejemplo, prettyer y ESLint. Necesitas analizarlo y realizar la operación. Lo mismo ocurre con ESLint. Así que esto es anulación.

Aunque estas herramientas pueden ser realmente geniales y lo son, hacen su trabajo. La cuestión es que no están conscientes entre sí. ¿Ves? Entonces, el hecho de que no estén conscientes entre sí también implica que la community necesita invertir mucho tiempo para compensar esta brecha. Un ejemplo, el complemento de ESLint para prettier. Un complemento que se escribió 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 invertir tiempo para sincronizarlos. Así que la community ha hecho mucho. Como el complemento de Tertser web hub. Así que nómbralos, hay un complemento para todo.

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

4. Estructura Compartida 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 están conscientes el uno del otro. Rome tiene como objetivo proporcionar diagnósticos de alta calidad y mejores errores para una mejor experiencia de desarrollo. 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 entre todas las herramientas. Así que hacemos una copia, se la damos al formateador, hace su propia tarea. Lo mismo ocurre con el linter. Su propia tarea, y esa operación se realiza una vez.

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

Diagnóstico de alta calidad. Así que este es bueno. ¿Alguna vez has visto este tipo de diagnóstico antes? Como token inesperado. ¿Qué es eso? Quiero decir, para ustedes, desarrolladores experimentados, ya saben qué es eso. Pero esto no es amigable para principiantes. Un principiante ve eso y se pregunta qué es YDR inesperado. OK. Así que con Rome, queremos proporcionar mejores errores. Este es un ejemplo de un diagnóstico para el mismo fragmento de código. Tratamos de decir, escucha, en realidad encontramos un retorno, no una R. Y esperamos una expresión. Aunque express aún no es amigable para principiantes, creo que es un paso hacia una mejor experiencia de desarrollo. Ahora, este es un diagnóstico de Rome. Y quiero explicar la anatomía de un diagnóstico.

Este es otro ejemplo de un diagnóstico proveniente de una regla de lint, ok, que también sugiere una acción de código. 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 hacer clic con el mouse y te llevará a la página de documentación y abrirá un navegador. Luego tenemos estas etiquetas o las llamamos etiquetas que proporcionan más metadatos al diagnóstico actual.

5. Diagnostic Fix and IDE Integration

Short description:

En este caso, tenemos un diagnóstico que se puede corregir. 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. Se sugieren acciones de código, pero pueden ser inseguras. En el IDE, vemos el mismo diagnóstico con un enlace a la regla. LSP admite acciones de código, incluida la supresión de la regla con una explicación.

En este caso, tenemos un diagnóstico que se puede corregir. Luego tenemos el mensaje y el color cambia según el tipo de diagnóstico. En este caso, es una advertencia. No es un error porque es amarillo. Tenemos el marco de código donde resaltamos el error. Luego también tenemos una sección donde proporcionamos- tratamos de proporcionar más información para dar contexto al desarrollador de por qué creemos que esto es realmente un error para esta regla.

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

Ahora te muestro el mismo diagnóstico en el IDE. De acuerdo. Como te dije antes, tienen que funcionar a través de la CLI y LSP. Entonces aquí tenemos el mismo fragmento de código. Esta es una captura de pantalla de VS Code que admite LSP. Como puedes ver, obtenemos el mismo mensaje, ok, con el enlace real a la regla. No obtenemos la nota o descripción real porque LSP no admite toda esta clase de información. Aunque tenemos... podemos proporcionar más acciones de código en LSP porque esta es una sección interactiva. Entonces realmente proporcionamos dos acciones de código. La primera es la que viste 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 Rome requiere una explicación cuando quieres desactivar la regla. Creo que esto es una buena práctica. Entonces realmente decimos por qué desactivaste la regla. Como se considera un comentario seguro. Como si quisieras usar el operador bang de time square, 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. Debe ser fácil de usar.

6. ROM Commands and Configuration

Short description:

ROM proporciona dos comandos con configuraciones predeterminadas muy buenas, lo que te permite usarlo sin un archivo de configuración. Funciona perfectamente con la extensión de VS Code y la CLI, proporcionando una CLI potente con muchas opciones. Puedes personalizar tu experiencia de formato utilizando tu archivo de configuración.

Entonces 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 configuraciones predeterminadas muy buenas. Entonces tenemos un conjunto de configuraciones predeterminadas realmente buenas, opcionales. De acuerdo. Eres libre de usar las configuraciones predeterminadas de ROM. Y no necesitas un archivo de configuración. Ni siquiera necesitas instalarlo en la extensión de VS Code y simplemente funcionará. Entonces puedes usar la versión empaquetada de la extensión de VS Code y listo. También puedes usarlo en la CLI y funciona. También tenemos una CLI realmente potente, por lo que también queremos proporcionar la mayor cantidad de opciones posible hasta cierto límite. Entonces no necesitas instalarlo como una dependencia. Puedes usarlo en la CLI y funcionará. Y luego simplemente usa tu archivo de configuración. Puedes desactivar tus reglas de lint, cambiar el estilo de publicación, 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 admite React. Las reglas se categorizan en grupos, incluido un grupo de vivero para reglas en desarrollo. La clasificación de importaciones está disponible como un analizador.

Entonces esto es como un ejemplo de la sección de la aplicación del comando de formato. Y como puedes ver, tratamos de proporcionar todas las opciones necesarias para personalizar tu experiencia de formato. Y ten en cuenta, si recuerdas, esa línea es la misma línea que te mostré antes en el JSON schema. Como puedes ver, eso también se genera automáticamente desde el código. Entonces nosotros, los desarrolladores, en realidad escribimos la documentation en el código fuente y luego la proporcionamos a ustedes. Entonces 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. En realidad, está destinado a ser un reemplazo de Prettier. Aún no admite 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. Admitimos JavaScript y todos los super lenguajes, también JSON.

El linter tiene casi 150 reglas. No hay tantas como en Lint, pero la community detrás de él sigue trabajando en agregar nuevas reglas. También tenemos 2 reglas de React. Todavía están en el grupo de vivero, por lo que este es en realidad un nuevo concepto que no existe en Lint, que son los grupos. Tratamos de categorizar en grupos las reglas para que realmente conozcas el contexto de tu regla. También debes desactivar las reglas del grupo de estilo. Entre estos grupos, tenemos un grupo especial llamado vivero. Este es un concepto que tomamos prestado del ecosistema de Rust, que es un grupo de reglas donde aún están en desarrollo. Pueden estar rotas. También es como una red de seguridad para nosotros, los desarrolladores y mantenedores, para reglas que están realmente rotas pero que son recomendadas de forma predeterminada y podemos degradarlas a vivero porque es como que hay un falso positivo y es difícil de solucionar. Entonces, simplemente las degradamos y no siguen el versionado semántico. Entonces, también es bueno para nosotros, los desarrolladores. También tenemos clasificación de importaciones. Es un analizador, no un 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, brindando soporte de diagnóstico similar a NCIL y LSP. Hay esfuerzos de la comunidad y complementos disponibles para varios editores, excepto IntelliJ. El analizador recuperable de Rome permite el 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 especializadas como formatear código con errores de sintaxis y vincular código roto. Rome puede analizar archivos de configuración y aplicar valores predeterminados solo a las secciones con errores.

Entonces, necesitamos analizar tu código para mover tus importaciones. Se integra con VCS y, bueno, VLSP como te mostré antes, funciona de inmediato. Los diagnósticos funcionan de la misma manera que NCIL y LSP. También hay esfuerzos de la comunidad en torno a esto. Hay complementos para Nix, Helix, NeoVim.

Hay una comunidad activa donde desarrollan complementos para editores que admiten LSP. Aún no hay soporte para IntelliJ, desafortunadamente. No admite LSP. Ahora quiero mostrarte algunas de las fortalezas de Rome. Algunas cosas que es posible que no hayas visto, son un poco controvertidas, pero te pido que me sigas. Creo que son buenas, pero es tu juicio.

Rome tiene un analizador recuperable. Un analizador recuperable es aquel que, cuando encuentra un error de sintaxis, no se detiene. Intenta reanudar el análisis correcto tanto como sea posible y luego intenta finalizar el análisis real hasta el final del archivo. Debe ser resistente a errores porque este tipo de analizador debe funcionar en los IDE. Los analizadores que tenemos en los IDE son los mejores 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 descartar esos tokens hasta que encuentra un token que tenga sentido. Por ejemplo, una llave que pertenece al cuerpo de una función. A partir de ahí, el analizador comienza a reanudar el análisis correcto y todos esos tokens que se descartaron desaparecen 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. Hemos tomado muchos conceptos de .NET y de este proyecto Roslyn. Es un gran proyecto si te interesa los compiladores. Entonces, ¿qué hay de eso? Quiero decir, está bien, tenemos este analizador recuperable, ¿qué podemos hacer con eso? Bueno, podemos hacer muchas cosas especializadas, como formatear código que tiene errores de sintaxis. Esto es bastante controvertido porque muchos desarrolladores, incluido yo mismo, usamos el formateador para determinar si el código es sintácticamente correcto o no. Esta es una función opcional. También podemos vincular el código roto. Creo que esto es bastante bueno. Entonces, no necesitas tener un código perfecto para recibir diagnósticos. También podemos analizar el archivo de configuración y aplicar nuestros valores predeterminados solo a las secciones que están rotas.

9. Analizando un Archivo de Configuración Roto

Short description:

Ahora, te mostraré 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 solucionar 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 demuestra en nuestra prueba de referencia.

Ahora, te mostraré un pequeño video. Puede ser rápido, pero luego lo descompondré y te mostraré lo que significa. Entonces, en este video, a la izquierda, hay un archivo de configuración que está roto. Hay un error de sintaxis. Y a la derecha, voy a intentar formatear un poco de código basado en el estilo de código ú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 qué sucedió.

De acuerdo. Ahora, ese es el archivo de configuración. Entonces, tenemos una coma faltante allí antes del linter y también después del outro. De acuerdo. 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 solucionar 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 recommended all que no pueden ser verdaderas al mismo tiempo. Entonces, durante la visualización del archivo de configuración, hubo un error. Ahora, lo bueno es que pudimos analizar realmente como un nodo o una sección que estaba realmente rota. De acuerdo. Entonces, logramos inspeccionar realmente como un buen código que estaba dentro del código malo. Entonces, Rome, mira, esto no es un error, pero Lisa aplicará mis propios valores predeterminados para ti. Y luego tenemos la acción de código del formateador que te muestra el estilo de código único. Entonces, si retrocedemos, agregamos el estilo de código único y aquí es lo que tenemos. Entonces, realmente logramos aplicar el formateador correcto. Ahora, Rome es rápido, ¿de acuerdo? Esta es una captura de pantalla de nuestra prueba de referencia. Entonces, en nuestro repositorio, tenemos una carpeta de prueba de referencia 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 ahora voy a intentar ejecutar Pretier, ¿de acuerdo, 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 todavía está activo con planes emocionantes. Aún 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 Rome es más fácil que hacerlo por ti mismo.

No tengo suficiente tiempo. Tengo que detenerlo. Toma demasiado tiempo. Ahora, voy a probar 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 unos pocos milisegundos. Gracias. De acuerdo, 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 Rome, de acuerdo. Entonces, voy a ejecutar su comando. Quiero decir, realmente funcionó, es tan rápido a veces que pienso que no funcionó pero no, funcionó. Entonces, ¿qué sigue para Rome? Entonces, el proyecto todavía está activo. Esta es una comunidad pequeña pero realmente enfocada y emocionada. Entonces, queremos dejar los archivos JSON, agregar nuevos lenguajes y establecer la base para el constructor. El bundler, más intros y demás. Entonces, hay mucho en marcha. Algunos datos personales si quieres seguirme o seguir a la comunidad de Rome y gracias. De acuerdo, 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 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 quisiera usar Rome? Entonces, estamos trabajando en importar todas las reglas de ESLint que son recomendadas por la herramienta a Rome. Tenemos una hoja de ruta con un problema general para intentar portar todas ellas. Y luego, como dije, hay algunos esfuerzos de la comunidad para intentar portar también otras reglas, también de TypeScript, ESLint. Entonces, si quieres, simplemente inicia una discusión y podemos hacerlo seguramente. De acuerdo. Entonces, probablemente sea más fácil para alguien contribuir a Rome en lugar de intentar hacerlo ellos mismos dentro de su propio proyecto. Sí. Aunque sea Rust, tenemos una sección de documentación realmente buena, contribuciones, quiero decir, y también el lenguaje, podemos ayudar a todos.

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

Short description:

El futuro de las herramientas de Rome incluye la capacidad de crear complementos de JavaScript. La comunidad está solicitando esta función y tenemos un concepto de prueba creado por un ex colega. Queremos establecer los cimientos de las secciones más importantes y desafiantes. Al comparar Rome con otras herramientas como TurboPack y SWC, nuestro objetivo es ser una cadena de herramientas que te permita utilizar tu CLI y mantener tu código fuente desde diferentes ángulos.

para abordar el problema y el lenguaje. Sí. Sí. Genial. Muy bien. Siguiente pregunta. Y mencionaste esto un poco, pero me gustaría saber, ¿cómo ves el futuro de las herramientas de Rome? ¿Hacia dónde te gustaría que vaya? Mencionaste, más o menos, lo que viene a continuación, pero tal vez incluso, más adelante en el futuro. Bueno, esa es una buena pregunta. Entonces, lo que realmente nos gustaría hacer, también es poder crear complementos de JavaScript. Esto es algo que la comunidad está solicitando mucho. Tenemos preguntas aquí sobre complementos. Así que esto es genial. Sí. Sí. Pero primero, nos gustaría intentar establecer los cimientos de las secciones más importantes las más desafiantes, pero creo que también las más importantes. También tenemos, como, un concepto de prueba para crear un complemento de JavaScript creado por un ex colega mío. Hay una rama allí que fue creada. Aún no la he revisado, pero... Está allí. Sabes que está allí. Y funciona. De acuerdo, siguiente. Genial. Muy bien. Siguiente. ¿Cómo se compara Rome con otras herramientas como TurboPack, SWC, BUN, similares, etc.? Eso son muchas herramientas. ¿Cómo se compara con otras herramientas? Sí. En nuestro ecosistema. Según entendí, SWC quiere ser un reemplazo de BUBBLE. De acuerdo. Nosotros también queremos ser eso, pero somos una cadena de herramientas. Así que quieres usar tu CLI

12. Ambición de Rome y Suposiciones de Diagnóstico

Short description:

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

y mantener tu código fuente desde diferentes ángulos. Entonces, para Martin, esto es algo que SWC no tiene. Y también TurboPack. TurboPack está destinado a hacer un trabajo muy bien, y eso es todo. Rome quiere ser algo diferente, una cadena de herramientas. Por lo tanto, es más ambicioso, habrá más trabajo y la calidad de este trabajo debe ser de primera categoría. Pero eso tiene sentido. El alcance es completamente diferente de esa manera. Sí, está bien. Entonces, ¿hay algo como TypeScript ESLint con verificación de tipos para Rome? Aún no. ¿No es bueno? Aún no? ¿Eso significa que está por venir? Queríamos intentar usar TypeScript para recopilar toda la información de tipos y luego convertirla en una estructura de datos que pueda leerse 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, intentar usar la herramienta existente y luego tomar prestado. Eso tiene sentido. Muy bien. Esto es algo que me emocionó. Entonces, ¿cómo decidiste qué diagnósticos proporcionar más contexto? ¿Te basaste en suposiciones, tal vez en investigación de usuarios? Sí, en realidad nos basamos en suposiciones. Tenemos algunos pilares en nuestra página de documentación donde tratamos de decir, okay, los errores deben tener el máximo contexto posible. Deben usar palabras fáciles de entender para principiantes. Así que tratamos de ser conscientes y asumir que el usuario es en realidad un principiante. Y en base a eso, tratamos de dar buenas sugerencias. Pero sí, nos basamos en suposiciones. Y en caso de que tomemos prestada y tratemos de replicar una regla de herramientas existentes, en realidad tomamos prestada su descripción. La modificamos un poco, pero damos los créditos y la fuente de la regla, porque ellos inventaron la regla, se merecen un crédito. Así es como hacemos suposiciones reales cuando intentamos proporcionar diagnósticos. Entonces... Sí, eso tiene sentido. Trabajo en documentación y recibo esa pregunta todo el tiempo. Como, si vas a poner ese esfuerzo, ¿cómo sabes por dónde empezar? Pero creo que lidiar con algunos de los problemas que obviamente enfrentas, como usar estas otras herramientas, ¿dónde podría alguien que se una al proyecto necesitar esa suposición? Como tuvimos un caso en el que teníamos la regla que estaba bajo una sección, y luego la comunidad vino a ayudar. Y con la discusión, en realidad cambiamos la redacción y también la categoría. Así que somos de mente abierta. No estamos cerrados. Queremos que la comunidad nos ayude si estamos equivocados. Queremos solucionarlo. Eso es una gran nota para terminar. Muchas gracias, Ema. Por favor, denle otro aplauso.

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

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

Workshops on related topic

JSNation 2023JSNation 2023
44 min
Solve 100% Of Your Errors: How to Root Cause Issues Faster With Session Replay
WorkshopFree
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).