Biome, Herramienta para Proyectos Web

Hola a todos. Hoy voy a hablar de Biome, la cadena de herramientas web. Antes de continuar con las presentaciones, voy a presentarme. Mi nombre es Emanuele Stoppa. Soy uno de los colaboradores principales del proyecto Biome y colaborador principal del proyecto Astra. Vivo en Irlanda, soy italiano, me gusta viajar y soy un ávido jugador de console que actualmente está jugando Final Fantasy VII.

Así que vamos con Biome. ¿Qué es Biome? Biome es una cadena de herramientas que busca proporcionar una única experiencia para tus proyectos web. En este momento, Biome ofrece un Formateador y un Analizador, y vamos a ver qué son esos. Además, como misión, debo trabajar y ofrecer la misma developer experience en la CLI y el LSP, para editores, y quiere ofrecer diagnósticos de alta calidad.

Ahora, ¿qué es una cadena de herramientas moderna? Bueno, el año pasado fui a la GIA nation y hablé sobre la antigua Biome que era Rome y ahora Biome y Rome querían tomar todas estas herramientas que queríamos que tú pudieras tener en tus proyectos web y ofrecer solo una única cadena de herramientas y usar solo teóricamente, solo usar eso para todo. Aunque, bueno, quiero decir, seamos realistas. Eso no es posible en este momento. Quiero ofrecer un punto de vista diferente de la cadena de herramientas moderna. Como una cadena de herramientas moderna, queremos ser los dueños de las operaciones clave que posee el software. Así que el análisis, diagnósticos, formato, el linter y las code suggestions, asistencias. Básicamente, las cosas que realmente nos importan en la cadena de herramientas. Como una cadena de herramientas moderna, también seremos informativos, innovadores y queremos ofrecer características que no has visto antes. Es realmente interesante. Quiero decir, veamos más a fondo lo que Biome puede ofrecer.

Así que hablemos del formateador. El formateador de Biome es compatible con Prettier. Esto significa que se formatea como Prettier y todos sabemos que Prettier ofrece una experiencia de formato muy agradable y con opiniones. Biome es un 97 por ciento compatible en el formato de archivos JavaScript, TypeScript, JSX y TSX. Y también ofrece las mismas opciones que Prettier, excepto algunas que decidimos eliminar porque consideramos que son antiguas y ya no son necesarias. Y algo que el formateador de Biome hace y que Prettier no puede hacer es formatear código roto. Sí, exactamente. Eso es lo que el formateador de Biome puede hacer. Es una función opcional y realmente funciona. En este video, tenemos la declaración while que está rota y le falta un paréntesis.

Usarías Prettier y no podrías hacer eso. Puedes optar por usar Biome y ahí lo tienes, tu formato funcionando justo, ya sabes, listo para usar. Esta es una de las características que una cadena de herramientas moderna como Biome puede proporcionar.

Avancemos con el analizador. El analizador es una característica bastante completa que ofrece cosas como linter y clasificación de importaciones. Como linter, Biome ofrece más de doscientos roles de lint. Algunos de ellos son bastante exclusivos de Biome. Muchos de ellos son tomados de ESLint y los complementos más populares de ESLint. El analizador también ofrece clasificación de importaciones lista para usar y los roles de lint de Biome son informativos y realmente te enseñan algo. Así que veamos qué significa.

Entre todos los demás roles, quiero mostrarte algunos roles exclusivos de Biome. Que no puedes encontrar en otros linters y esperemos que los otros linters los adopten. Por ejemplo, use while o otro realmente bueno es no cost enum, que es bastante bueno y veremos qué hace. Así que quiero decir, no solo copiamos y pegamos lo que tenemos, sino que Biome ofrece algo más de lo que las herramientas existentes tienen para ofrecer. También ofrece una clasificación de importaciones, por lo que la clasificación de importaciones de Biome es solo un rol de asistencia. Es solo una regla diferente de un rol de lint, pero aún una regla que hace esencialmente la clasificación de importaciones. Y Biome tiene su propia lógica, que se explica en la documentation. Y esencialmente es una prueba de cuán poderosa es la infraestructura del analizador de Biome. Y también es informativo. Internamente tenemos esto que llamamos pilares de reglas. Cuando creamos el rol, tratamos de adherirnos a estos pilares. ¿Y cuáles son esos? Entonces, una regla podría explicarse como una primera regla que te explica el error, como, okay, se activó una regla. Realmente quieres saber por qué se activó. Pero en realidad, queremos saber el error real. Pero también quieres saber por qué se activó. No puedes simplemente decir, okay, esto es un error. Una regla debería decirte por qué. Para que sepas y aprendas de la regla real. Y luego, como tercer pilar, una regla siempre debería explicarte qué debes hacer. Okay, obtienes el error, sabes por qué, pero ahora ¿qué hago? Así que la mayoría de las veces obtienes la code solución.

Entonces, la regla sugiere cómo puedes arreglar tu code y luego optas por una solución. Pero si no tiene la solución, al menos debería sugerirte qué debes hacer. Como eliminar esto, cambiar esto o simplemente no usar esa sintaxis. Así que este tipo de cosas y estos son los pilares. Por lo tanto, están en nuestra documentation. Tratamos de adherirnos a esto. Esto es solo un ejemplo. Entonces, tomamos esta regla, Knock on Steam te habla sobre el error. Te dice por qué no deberías hacer esto. Y al final, te ofrece una solución de code. Perfecto, hemos tenido un vistazo a un diagnóstico. Entonces, el diagnóstico se usa generalmente para dar mensajes a los usuarios, a los desarrolladores. Y como puedes ver, son bastante refrescantes, ya sabes, son diferentes y también agradables de ver.

Entonces, desglosemos estos diagnósticos, ¿de acuerdo? Perfecto. Como puedes ver, en la parte superior izquierda, tenemos el archivo que activó la regla y también tenemos la fila y la columna del error. Luego ofrecemos esta categoría de diagnóstico, que generalmente en este caso, es esencialmente el nombre de la regla, pero a veces puede ser como una verificación de formato. Depende del contexto. Luego tenemos esta otra cosa que llamamos etiquetas. Las etiquetas son metadatos que deberían indicar la naturaleza del diagnóstico. Entonces, en este caso, `fixable` significa que es un diagnóstico de algo que se puede arreglar. También tenemos `internal`, que es algún error que lanzamos internamente. Es un error interno, no causado por el usuario. Luego el mensaje real, un marco de código, más mensajes. Tiene una `I`, lo que significa que es una información. Podemos ofrecer información adicional al diagnóstico. Y luego también podemos tener una acción de code que ofrece otro marco de código y otro mensaje. Bonito, ¿verdad? Perfecto.

Esto fue una introducción a lo que Biome ofrece. Y ahora, Biome es realmente joven.

Nació a finales de agosto, principios de septiembre, pero logró mucho. Y te mostraré qué. Así que Biome ganó el Desafío de Prettier. Hace unos meses, el creador de Prettier abrió una recompensa diciendo: `Si puedes crear una alternativa a Prettier con Rust, te daré $10,000`. Esos $10,000 se convirtieron en $20,000. Y ganamos el desafío, Biome lo hizo. Logró un 25% de compatibilidad, pero ahora incluso más con Prettier usando Rust. Esto se logró gracias a nuestra comunidad. El dinero se distribuyó entre todas las personas que contribuyeron al desafío. Solo una pequeña cantidad se mantuvo en nuestro colectivo abierto. El resto de los fondos se distribuyeron proporcionalmente según la cantidad de contribuciones que las personas hicieron durante el desafío. Hace unos días, alcanzamos las 20,000 descargas semanales. Así que en seis meses, esto es realmente un gran logro.

También obtuvimos patrocinadores. Tenemos un patrocinador oro y dos patrocinadores bronce. Si estás buscando visibilidad, creo que Biome es un proyecto realmente bueno. Te brinda exposición a todos estos desarrolladores que están migrando a Biome o probando Biome para tener una experiencia de desarrollo diferente o incluso mejor. También fue reconocido por otros desarrolladores en la comunidad en Twitter. Y estaban realmente satisfechos con la experiencia del usuario y la experiencia de desarrollo que ofrece Biome. También tenemos una comunidad en crecimiento con una gobernanza adecuada aquí. Todas las personas que forman parte del equipo de mantenedores y colaboradores, básicamente.

Ahora, hablemos un poco sobre Biome en 2024. En enero, publicamos nuestra hoja de ruta. Es una hoja de ruta anual. Solo tenemos un grupo de colaboradores y voluntarios que hacen esto en nuestro tiempo libre. Por lo tanto, no podemos hacer cosas como las grandes empresas pueden hacer. Pero queremos ser realistas. Queremos ofrecer algo alcanzable. Entonces, en 2024, lo que queremos lograr es lo siguiente. Queremos intentar ofrecer soporte para más lenguajes.

CSS ha sido completado. Ahora estamos trabajando en el formato y linting. A continuación será HTML y probablemente Markdown, más adelante. Queremos ofrecer más capacidades. Con esto, podemos hacer que nuestras herramientas actuales sean aún más poderosas, como el análisis de proyectos y el análisis de dependencias. Esto nos permitirá proporcionar más roles de linting y hacer que las reglas actuales sean más poderosas.

Transformaciones como compilar tu TypeScript a JavaScript o JSX a JavaScript. Formateo incrustado. Al igual que Pretier, donde tienes tu CSS con las plantillas literales, esto es algo que nos gustaría lograr y explorar. El linting cruzado es una característica que tal vez solo Pion pueda hacer u ofrecer. Esencialmente, un ejemplo podría ser que tienes tus clases CSS que se analizan en archivos CSS y luego tienes JSX y en realidad podríamos hacer linting si estás usando clases CSS que no pertenecen, que no están definidas en los archivos CSS. Exploramos plugins. Estamos explorando plugins. Ya tenemos algo de trabajo allí y varios RFC. Aún no sabemos cómo se verá un plugin de Pion. ¿Cómo puedes hacer eso? Pero en realidad estamos comenzando, comenzamos a dar forma a este gran y deseado tema. Y también queremos explorar la inferencia de tipos. No queremos reemplazar a TypeScript, el verificador de tipos. Eso es irrealista. Queremos explorar la inferencia de tipos. Entonces, tener una infraestructura capaz de inferir tipos dentro del código y luego proporcionar reglas de linting que aprovechen esta inferencia de tipos ávida.

Eso es todo para Pion. En realidad, no, hay una cosa más que creo que es la más importante que no he mencionado, pero no he olvidado. Pion es increíblemente rápido. Además de ofrecer nuevas características y diagnósticos y todo ese tipo de cosas, en realidad es muy, muy rápido. Es hasta cinco veces más rápido que ESLint en un solo hilo y es más rápido que PTR y Dprint en órdenes de magnitud. Pion aprovecha hilos individuales, aprovecha canales y aprovecha una lógica realmente excelente en términos de almacenamiento en caché y gestión de memoria. Algunas de estas cosas son posibles en el ecosistema de JavaScript, pero otras no son alcanzables con la herramienta que ofrece JavaScript. ¿No me crees? Bueno, aquí tienes un pequeño video.

Así que descargué tres repositorios, Rollup, Webpack y el antiguo RomTools cuando estaba en TypeScript y compruébalo tú mismo. Simplemente ejecuto el comando de verificación, que básicamente ejecuta un formateador y el analizador en toda la base de código y no he impreso ningún diagnóstico solo para mostrarte lo rápido que es analizar los archivos. Y sí, como puedes ver, la base de código de Webpack tardó aproximadamente un segundo para 6,000 archivos y cinco segundos para 13,000 archivos en su repositorio de herramientas. Quiero decir, el repositorio de herramientas también contiene archivos enormes y complejos para probar la conformidad de los archivos JavaScript y cosas así, y ver cuánto tiempo tardó. Así que sí, eso es una de las cosas más emocionantes de Pion y realmente funciona. Pruébalo tú mismo. Muchas gracias y que tengas un buen día. Muchas gracias por unirte a nosotros, Emmanuel. En primer lugar, pasemos a la pregunta de la encuesta que hiciste al público al principio y echemos un vistazo aquí. En general, preguntaste, ¿usarías Pion en un nuevo proyecto en lugar de usar la combinación de Prettier y ESLint? Mayoritariamente, la gente respondió tal vez. ¿Te sorprende? Es una sorpresa. Sí, sí. Me sorprende, pero positivamente. Quiero decir, considerémoslo, sabes, sé que Pion todavía no es tan maduro como estas otras dos herramientas, pero quiero decir, el hecho de que la gente esté dispuesta a darle una oportunidad para probarlo. Es bueno. Pion nació hace aproximadamente seis meses, más o menos, así que es bueno. Sí. Y también siento que es lo típico, no es escepticismo, pero obviamente, cualquier cosa que introduzcamos en la base de código, también somos responsables de ello, ¿verdad? No queremos ser los que introdujeron algo completamente nuevo y luego, ya sabes, alguien se queje de ello porque lo introdujimos de manera imprudente. Siento que tal vez, un tal vez rotundo, con, ya sabes, el segundo lugar siendo muchas personas diciendo sí, por cierto, lo cual también es muy bueno de ver, ya sabes, obviamente eso es algo muy de desarrollador. Claro. Como, lo consideraré. Lo miraré. Y siento que, ya sabes, tal vez definitivamente es una buena preparación para un sí. Así que muchas gracias a todos por enviar eso. Siento que esto es muy alentador para Emmanuel, mientras hablamos, los síes van aumentando. Así que sigamos con la conversación aquí un poco. ¿Quién sabe? Tal vez el sí lo supere. Siento que eso te haría un mantenedor de código abierto muy, muy feliz, Emmanuel. Pasemos a las preguntas, si podemos resaltar esas.

Y la primera pregunta es, ¿puedes compartir algunas ideas sobre la inferencia de tipos que se mencionó en la hoja de ruta? Claro. En la hoja de ruta, explicamos brevemente que queremos probar un enfoque diferente, en lugar de simplemente reemplazar TypeScript, que ahora es el verificador de tipos de facto del ecosistema web, intentar tener un enfoque diferente, como usar una inferencia de tipos, que es diferente de un verificador de tipos. Así que se trata simplemente de tratar de adivinar tanto como sea posible para ser como una inferencia ansiosa, y proporcionar la infraestructura suficiente para reemplazar esas reglas de linting de ES que requieren verificación de tipos exactamente. Todas estas reglas que muchos usuarios están solicitando, queremos intentar proporcionarlas utilizando este proyecto de inferencia de tipos. También hay algunos trabajos en la web. Hay este proyecto llamado ESNO que utiliza este tipo de heurísticas. Y funciona incluso para JavaScript. Incluso no necesitas TypeScript. Y eso es lo que queremos intentar lograr. Genial. La siguiente pregunta, siento que es más filosófica. ¿Crees que llegará un momento en que el linting de proyectos JavaScript o TypeScript se vuelva innecesario porque mantener la configuración de ES lint a menudo es una carga enorme para un beneficio marginal de linting? ¿Cuáles son tus pensamientos al respecto? No lo creo. No lo veo, para ser honesto. JavaScript es un lenguaje realmente dinámico. Y debido a eso, puedes hacer de todo. Puedes romper todo, contaminación de prototipos, puedes cambiar todo. Entonces, los linters están ahí solo para evitar ciertos patrones peligrosos, intentar corregir errores y encontrar cosas que se pueden encontrar durante la fase de análisis. Debido a eso, en realidad creo que es algo que deberíamos mejorar en el futuro, tener mejores herramientas que se encarguen de todo. Y puedes escribir código con tranquilidad y sin preocuparte por problemas de seguridad u otras cosas. Esa es la naturaleza del lenguaje. Pero también hay otras herramientas más estrictas como Rust y otros lenguajes de tipado estricto que requieren este tipo de análisis. Entonces, sí, quiero decir, no veo un futuro sin ellos.

Es bastante interesante, ¿verdad? Si observamos otros lenguajes como el lenguaje Go, por ejemplo, tienen el linter integrado en el diseño del lenguaje, lo cual creo que es muy revelador. Personalmente, es interesante. Me gusta esta pregunta porque, por un lado, no me importa si las personas agregan un punto y coma allí o cuántos espacios usan. Siento que es casi un ejercicio tonto tener algo que constantemente reformateará. Pero lo que estás planteando es en realidad el aspecto de seguridad, ¿verdad? Ayuda a evitar patrones peligrosos. ¿Qué dirías sobre el formateo automático del código? La parte de Prettier, ¿cuál es el beneficio de eso y por qué sigue siendo una buena idea que Biome se encargue de hacer que el código sea bonito, en esencia? Sí, sí. Bueno, al observar otros lenguajes y ecosistemas, el hecho de tener todos los proyectos formateados de manera más o menos similar es realmente bueno porque puedes pasar de una base de código a otra y ver cada vez los mismos patrones, la misma forma en que el código está formateado.

En realidad, es muy bueno porque también se crea un estándar en todo el lenguaje, aparte de pequeños cambios que, ya sabes, es un formateador. Por lo tanto, se basa en preferencias estilísticas. Disfruto de los formateadores. Me gustan. Quiero decir, no podría vivir sin ellos. Así que me gustan. Por eso promuevo su uso. Pero quiero decir, hay personas que no los necesitan. Pero al observar otros lenguajes, es una gran DX (experiencia de desarrollador). Siento que es un argumento muy sólido. Echa un vistazo a otros lenguajes. Ya lo tienen incorporado. Excelente. ¿Cuál es el progreso actual en cuanto al soporte de plug-ins? Esa es una de nuestras próximas preguntas. Ah, esa es una gran pregunta. Entonces, el progreso es que estamos explorando un enfoque DSL para las reglas de linting. Uno de los miembros principales ha elegido este lenguaje llamado grid QL. Ya tenemos un analizador para analizar este lenguaje de consulta. Y ahora estamos trabajando en el motor. Así que tener una forma de crear reglas de linting utilizando el DSL y luego Biome te proporciona análisis de datos. Esa es la idea inicial de nuestros plug-ins. Muchas personas han solicitado APIs de JS y TypeScript. También las exploraremos. Pero requerirán más tiempo porque siempre se salta de un binario a otro binario. Así que hay mucho trabajo en ello. Y requerirá más tiempo en términos de performance (rendimiento), que es algo importante para Biome porque necesita ser rápido. Eso es algo en lo que nos preocupamos.

Genial. Muchas gracias.

Súper, súper fascinante ver todo esto. Entonces, tal vez como última pregunta, si pudieras dar a la gente un breve vistazo al futuro, ¿qué deberían esperar los usuarios de la versión dos de Biome?

Para la v2, vamos a eliminar todas las obsolescencias que introdujimos cuando luchamos con Biome. Así que, como todas las cosas de Rome que teníamos, planeamos renovar la configuración porque somos una cadena de herramientas. Tenemos una gran configuración. Queremos refinarla en base a los comentarios de los usuarios. Y nuestros otros proyectos están abordando ciertas cosas como el linting y cosas así.

También vamos a renovar la CLI para tener más comentarios que sean iguales en opciones que sean iguales en comentarios. Así que no veo muchos cambios disruptivos, pero el que prevemos, también podemos proporcionar algunos patrones de migración para que la gente no tenga que asustarse demasiado. Tenemos nuestro propio comando de migración que se encarga de todo. Así que esperamos no proporcionar demasiados cambios disruptivos para la v2.

Increíble. Muchas gracias, Emmanuel, por estar aquí en esta sesión de preguntas y respuestas. Y también gracias de nuevo por esta charla realmente, realmente increíble. Estamos súper emocionados de tenerte aquí. Gracias de nuevo, Emmanuel. Gracias por tenerme y espero que disfruten mi charla.