El Código Muerto No Debería Existir: Cómo Eliminamos 28k Líneas de Código, Un Knip a la Vez

He estado en esta conferencia durante los últimos cuatro años, así que esta es mi quinta vez en React Summit y Chase Nation. Pero en realidad es la primera vez que doy una charla en persona aquí. Así que estoy realmente feliz y emocionado de hablarles sobre KNIP y la eliminación de código muerto hoy. Mi nombre es Dominik. Soy un ingeniero de software de Viena. Y como acabas de decir, también puedes encontrarme como tk.dodo en línea casi en todas partes, principalmente en Blue Sky estos días. Y también escribo un blog en tk.dodo.eu, principalmente sobre TypeScript y React.

Y por supuesto también sobre React Query o 10-Stack Query, que es la biblioteca de código abierto que he estado manteniendo durante los últimos cinco años. Ahora, una pregunta rápida. Levanta la mano si has trabajado con 10-Stack Query o React Query antes. Oh, eso es un montón de manos. Eso es genial. Siempre me encanta ver eso. Sin embargo, no estoy aquí para hablar sobre 10-Stack o React Query hoy. Tengo algunas pegatinas de 10-Stack si quieres. Así que puedes venir a mí después y tomarlas.

Y también hay algunas charlas más mañana sobre 10-Stack. Pero hoy quiero hablarles sobre algo diferente porque a principios del año pasado, me uní al equipo de ingeniería de diseño en Sentry, donde no estamos trabajando directamente en una parte específica del producto, sino que nuestro objetivo es hacer que el envío suceda. Queremos permitir que otros equipos envíen de manera eficiente. Y en ese sentido, nuestro equipo realmente apunta a hacer posibles dos cosas. Queremos facilitar a los equipos de producto el envío de las cosas correctas de manera eficiente y consistente.

Y al mismo tiempo, guiarlos para no enviar cosas incorrectas o inconsistentes y llevarlos a ese pozo de éxito por defecto. Y para llegar allí, una gran parte del trabajo de nuestro equipo es construir un sistema de diseño, que es una biblioteca de componentes consistentes con buenas APIs y documentación y seguridad de tipos y accesibilidad incorporada. Porque esos componentes necesitan ser fácilmente descubribles para que los desarrolladores de productos puedan componerlos y enviarlos rápidamente sin romper cosas.

Y para el segundo punto, estamos trabajando activamente en restricciones. Eso significa configurar TypeScript y linting, pero también la estructura del proyecto y la documentación y la enseñanza y también las habilidades de IA hoy en día juegan un gran papel en eso. Así que, en resumen, intentamos llevar la base de código general de Sentry que ha crecido orgánicamente durante los últimos 10 años a una buena forma para que tanto los humanos como sus agentes puedan enviar rápido. Y eso significa que tenemos que tocar muchas partes de la base de código regularmente.

Por ejemplo, mi primer PR en Sentry tocó más de 900 archivos porque habilité la configuración del compilador no implicit any, lo cual me sorprendió mucho que no estuviera activado, para ser honesto. Y mientras hacía esto y algunas otras mejoras, a veces me preguntaba si tal vez debería, ya sabes, verificar la cordura de las cosas que estaba tocando o al menos averiguar dónde se usan. Y a veces resulta que no se usaban en absoluto.

Así que cuando introduje el plugin ESLint query para verificar si los hooks de React query están funcionando eficientemente, obtuve un montón de violaciones, como en este hook, e intenté arreglarlas. Y después de luchar con esto por un tiempo, quise averiguar dónde se usaba. Y resulta que no se usaba en absoluto en la base de código. Así que pensé para mí mismo, OK, eso es todo. No más. Esto me está ralentizando. Estoy perdiendo mucho tiempo aquí. Tengo que limpiar la casa porque el código no utilizado tiene un costo real. Significa que los desarrolladores pasarán tiempo leyendo y tratando de entenderlo, tal vez incluso refactorizando código que no debería estar allí en primer lugar.

Y creo que esto se vuelve aún más importante en la era de la IA, donde generar código extra es fácil, pero mantenerlo a lo largo del tiempo es realmente difícil, y cada línea de código no utilizada podría aún consumir tokens o inflar la ventana de contexto de los agentes. Y las actualizaciones de bibliotecas o cambiar las reglas de lint se vuelven más dolorosas cuanto más usos tenemos, porque esas herramientas no se preocupan si el código se usa o no. Si existe, tiene que estar libre de errores. Y podría incluso aumentar nuestro tamaño de paquete si no se elimina correctamente con tree-shaking, por ejemplo, si tenemos módulos con efectos secundarios.

Así que, en general, creo que el código no utilizado es un dolor. Aumenta la carga cognitiva. Y por eso deberíamos preocuparnos por ello. Nos ralentizará. Entonces, ¿cómo terminamos aquí? Bueno, me gusta pensar que los ingenieros son generalmente seres responsables que les gusta limpiar después de sí mismos, pero en verdad, tenemos que ser constantemente recordados sobre las formas más básicas de limpieza. Y creo que con razón estamos impulsados por errores, porque TypeScript nos da mucha confianza. Toma todas esas dependencias que solían estar en nuestra cabeza, y las hace explícitas en el código.

Por ejemplo, puedo cambiar algo en la función cuando devuelve, y me mostrará todo el impacto que tendrá. Y esto es algo que era realmente difícil en JavaScript puro sin tipos, especialmente en bases de código más grandes. Y con TypeScript, todo eso se vuelve explícito. Ahora, eso es enorme para nuestra productividad y confianza. Pero también hemos llegado a depender mucho de esto.

Y no es solo TypeScript. También es todo el linting y testing y todos los demás carriles de seguridad y análisis estático que hemos configurado en nuestras pipelines de CI. Porque si lo que estamos tocando no aparece en rojo en algún lugar, generalmente significa que lo que estamos haciendo todavía está permitido o se considera una buena práctica en esta base de código. Y probablemente no buscaremos más allá de eso. Y creo que así de simple es como ese código permanece. Si nadie nos dice que lo eliminemos, probablemente no lo haremos.

Bien, entonces podrías estar pensando, espera un segundo, ¿no detecta esto TypeScript, verdad? Ahí está mi buen amigo, TS6133 algo está declarado, pero su valor nunca se lee. Todos hemos visto esto cuando olvidamos una importación o algo, ¿verdad? Este es un error fácil de TypeScript. Entonces, ¿no detecta esto TypeScript? Y la respuesta es sí y no, depende de la situación.

Supongamos que tenemos este ejemplo muy simple, un componente de React llamado filesize, y tiene una función utilitaria format bytes. Ahora, si este es el único lugar donde usamos esta función utilitaria, si eliminamos el componente, entonces sí, TypeScript nos dirá que podemos eliminar esta función de manera segura si tenemos la bandera no unused local activada, que creo que está activada por defecto. Pero, ¿qué pasa si cambiamos una pequeña cosa? ¿Qué pasa si añadimos una declaración de exportación delante de format bytes? Bueno, entonces TypeScript no reportará ningún error en absoluto, porque TypeScript simplemente no realiza análisis de uso entre módulos. Si algo se exporta, entonces TypeScript simplemente asumirá que se usa en otro lugar y no reportará ningún error al respecto. Y sí, en este escenario simple, esto podría no ser un problema. Pero en la práctica, lo que suele suceder es que esas dos cosas tienden a separarse. Como que los utils se mueven a un archivo separado, tal vez se vuelven globales, se usan en otro lugar, y luego los usos se eliminan con el tiempo. Y lo que sucede es que lo que queda es esta función utilitaria que nadie usa más. Y creo que esa es la forma más fácil y común de producir ese código. Y la IA también lo hace todo el tiempo cuando toman un enfoque y luego toman otro enfoque y dejan mucho de ese código atrás.

Ahora, buenos IDEs pueden ayudar con eso. Por ejemplo, IntelliJ crea un índice de todo y luego marcan estas cosas visualmente, pero aún depende de los desarrolladores actuar sobre eso. Y pensé, ya sabes, esto no puede ser todo. Seguramente alguien más debe haber tenido el mismo problema y ya construyó una herramienta para esto, ¿verdad? Y resulta que en realidad hay un par de herramientas que intentan ayudar con esto. Hay herramientas como tsprune o unimported, y han existido durante bastante tiempo. Pero lo que todas tienen en común ahora es que están obsoletas o no se mantienen y que recomiendan KNIP de Lars Kuppert en su lugar. Entonces, ¿qué es KNIP? Bueno, KNIP es una herramienta integral para analizar estáticamente tu código en busca de archivos, exportaciones y dependencias no utilizadas, y luego informarte para que puedas eliminarlas. Es bastante rápida. Toma alrededor de seis segundos en la base de código bastante grande de Sentry. Intenta ser de cero configuración, aunque en cualquier repositorio más grande, podrías necesitar un poco de configuración. Y tiene muchos plugins, soporte para monorepos y también es auto-corregible.

Ahora, eso es un buen argumento de venta, pero ¿cómo funciona realmente? Entonces, en su núcleo, KNIP necesita saber dos cosas. Tiene que saber qué archivos son parte de tu proyecto. Y lo complicado que es eso generalmente depende de la estructura de tu producto, pero puede ser tan simple como todos tus archivos TypeScript en tu directorio de origen. Y la segunda cosa es que tiene que saber dónde están los puntos de entrada de tu aplicación. Y cuáles son los puntos de entrada, eso varía drásticamente según el bundle o framework que estés usando. Por ejemplo, si estás usando Next.js, entonces cada archivo page.tsx o layout.tsx en tu directorio de aplicación tendría que ser uno de esos puntos de entrada. Pero si solo estás usando Vite, por ejemplo, podría ser solo tu archivo main.tsx. Y una vez que KNIP sabe eso, recorrerá el proyecto, comenzando desde los puntos de entrada para construir un gráfico de esos símbolos utilizados. Y luego simplemente informará sobre las cosas que están en el proyecto, pero no en ese gráfico.

Entonces, en este ejemplo, tenemos tres puntos de entrada. Está recorriendo todos los puntos verdes, y luego encontrará esos dos puntos rojos y los reportará a usted, porque son parte del proyecto, pero no son utilizados por ninguno de los puntos de entrada. Y eso es prácticamente todo.

Y funciona notablemente bien. Creo que es mejor si le muestro una pequeña demostración ahora de cómo funciona. Así que vamos a la demostración. Solo verifiquemos si esto es lo suficientemente grande. Sí, eso se ve bien. Así que esta es la base de código de Sentry. Sentry es de código abierto. El código está en GitHub. Puede revisarlo usted mismo. Pero tuve que hacer un poco de trampa. Tuve que retroceder en el tiempo, porque ahora ejecutamos KNIP en ZI. Y cuando haces eso, ya no tenemos código no utilizado. Pero retrocedí un poco en el tiempo a un lugar donde todavía teníamos código no utilizado. Así que ejecutemos KNIP aquí y veamos qué reporta.

OK. Así que KNIP nos muestra tres exportaciones no utilizadas, tarjetas de front-end, tarjetas de back-end y tarjetas móviles en un archivo llamado Vital Cards. Así que vayamos allí. Y luego, dentro de Vital Cards, podemos ver que mi editor muestra que esto no se utiliza y que no hay usos de esta cosa. Pero no hay nada más que informe esto, pero KNIP sí lo hace. Así que eliminemos esto. Y luego veremos que aparecen algunas cosas más, porque ahora tenemos un local que no se utiliza. Y ahora TypeScript diría con el TS6133, que esto tampoco se utiliza. Podemos continuar eliminando eso. Así que hagámoslo. Solo eliminemos todo eso. Y luego teníamos las tarjetas de back-end. Es lo mismo.

Vamos a eliminar eso. Y luego las tarjetas móviles también. Y luego veamos. Hay algunos más tipos que podemos eliminar.

Y de repente, aparece algo más. Están estas tarjetas genéricas, probablemente que fueron utilizadas por estos tres. Así que KNIP nos muestra esto también.

Y luego hay más. Siempre hay más cosas apareciendo. Solo iba a seguir moviéndome hasta que todo lo rojo desaparezca. Gráfico Sparkline. Eso es interesante. No necesitamos eso. Más cosas.

Así que KNIP es simplemente el regalo que sigue dando. Siempre hay más cosas. Esto se va. OK. ¿Qué es esto? Fuera. Más tipos. No los necesitamos. Algunas cosas más. Otra función. OK. ¿Es esta la última? No lo es. OK. Genial. Bueno, ahí lo tienes. Componentes estilizados. Bah. Los odio. OK. Genial. Correcto. Tipos. OK. Hay algunos más. Sí. Me encanta esto. Esto es extrañamente satisfactorio. ¿Conoces la sensación de eliminar código? Es genial. OK. Ahora mira todas estas importaciones. Hay tantas importaciones.

Boom. OK. Perfecto. Ahora todo lo rojo ha desaparecido. Así que veamos qué hicimos. Pasamos de 565 a 191 líneas de código. Así que casi hemos eliminado como dos tercios de ese archivo debido a estas tres cosas que KNIP nos mostró inicialmente.

OK. Así que ahora hemos terminado, ¿verdad? Encontramos este archivo. Lo hemos limpiado. Eso es realmente bueno. Pero, ¿hemos terminado ya? Hemos eliminado todas esas importaciones, ¿verdad? Solo para estar seguros, ejecutemos KNIP nuevamente para ver si hay algo más que podamos eliminar.

Oh, sí. Ahora elegí más cosas. Eso es genial. Así que echemos un vistazo a eso. Tenemos este sparkline. Aparentemente, teníamos este gráfico de sparkline y este era el único que usaba estas cosas de sparkline. Así que ahora tenemos todo este directorio que podemos eliminar. Y aún mejor, podemos ir a nuestro package.json y eliminar una dependencia como sparkline chart. En realidad, no lo hemos necesitado por un tiempo, pero todavía estaba aquí y probablemente lo estábamos actualizando. Así que ahora eso puede desaparecer. Y luego todavía tenemos dos cosas más que encontró, dos utils.

Uno de ellos es este de aquí. Y eso es especialmente interesante porque no tiene cero usos. Solo tiene un uso, pero está en el mismo archivo. Así que no podemos eliminarlo completamente. Pero lo que podemos hacer es eliminar las declaraciones de exportación. Se convierte en un util local que luego puede ser limpiado adecuadamente si el último uso realmente desaparece. Y luego tenemos este de aquí, detalles vitales de la tarjeta, otra función que se puede eliminar.

¿Traerá esto más cosas? Sí, lo hará, obviamente. Muchas más importaciones que podemos limpiar. Eso es bueno. Bien. Así que ahora hemos terminado, ¿verdad? ¿Hemos terminado? No lo sé. Tenemos que pedirle a Knip que lo ejecute de nuevo para ver si hay más cosas que podemos eliminar. Muy bien. Eso es genial. Así que ahora dice que Knip no encontró problemas. Y esto es realmente lo que queremos ver. Entonces sabemos que hemos terminado y podemos hacer un PR y realmente estar seguros de que hemos limpiado todo lo que necesitamos.

Bien. Esto fue genial. Fue muy divertido. Leer todo este código completamente no utilizado. Pero pensamos que tal vez podemos hacerlo mejor. Porque a veces, no sé, los desarrolladores hacen esta cosa llamada escribir pruebas. No sé si estás haciendo esto. Tal vez tus agentes de IA lo estén haciendo por ti estos días. A la IA le encanta escribir pruebas. Así que imagina lo que sucede si tenemos código que no se usa en producción, pero aún tiene una prueba. Técnicamente, no está sin uso. Hay un uso.

Pero tanto el uso, la prueba, como el código de producción real pueden ser eliminados porque no lo necesitamos más. Y en esos casos, no solo tenemos que mantener ese código, también ejecutamos las pruebas en CI. Y si esas pruebas son inestables, las volvemos a ejecutar sin razón todo el tiempo. Y eso es doblemente doloroso.

Así que la verdadera pregunta es, ¿puede Knip detectar eso también? Y la respuesta es sí, puede, porque tiene un modo de producción dedicado. Y en el modo de producción, solo se enfoca en el código que realmente enviamos. Y para eso, Knip debe saber qué es una entrada de producción y qué archivos son parte de tu código de producción. Y para llegar allí, tiene una sintaxis especial.

Quiere que marquemos el código de producción con un signo de exclamación al final. Ahora, por ejemplo, eso significaría que cada archivo TSX en source ahora tendría el signo de exclamación al final porque es código de producción. Y el source main.tsx es el punto de entrada de producción. Y luego podríamos tener algunos scripts de construcción adicionales en el directorio de build que no son parte del código de producción.

Así que esos archivos serían invisibles en ese modo de producción. Y esto funciona muy bien si tu proyecto está bien estructurado. En Sentry, se ve más así. Pero eso es principalmente porque no tenemos un lugar dedicado para poner nuestros ayudantes de prueba y fixtures. Así que tenemos que excluirlos con un signo de exclamación al principio del modo de producción. Así que la sintaxis es un poco extraña. Requiere un poco más de configuración. Pero vale totalmente la pena configurarlo. Porque hay tantas cosas que puede mostrarte que ni siquiera los IDEs te mostrarán.

Solo un ejemplo es que teníamos esta función getIncidentDiscoverUrl que tenía pruebas pero ningún otro uso. Y pudimos eliminarla de manera segura. Y al final del día, creo que fue más de dos tercios de todo el código muerto que eliminamos que provenía del modo de producción, que es básicamente pruebas más el código real en sí mismo. Y así creo que vale totalmente la pena configurarlo también. Ahora, en general, creo que pudimos eliminar mucho de ese código con Knipp. Pero también hubo algunos problemas. Y dado que esta es una historia de la vida real, tenemos que reconocer que no todo salió perfecto en este plan. Y hubo algunos problemas y limitaciones con los que también nos encontramos.

Y creo que quiero compartirlos contigo también. Ahora, probablemente el más grande es que influye en cómo trabajamos. Y Sentry tiene cientos de desarrolladores contribuyendo al código regularmente. Así que cualquier cambio en cómo trabajamos es potencialmente disruptivo. Porque una cosa que tendemos a hacer es que vamos a agregar código a veces en PRs que no tienen un uso explícito en este momento porque queremos usarlos en un futuro PR. Ahora, por supuesto, si ejecutas Knipp en CI, no puede diferenciar entre los dos. Así que un PR que hice fue cerrado porque encontré código que se agregó hace seis meses y estaba aún sin usar. Pero resulta que esto simplemente fue despriorizado en el producto. Y todavía había planes para usarlo. Ahora, con Knipp ejecutándose en CI, simplemente no funciona tan bien trabajar de esa manera. Hay formas de optar por no usar Knipp, por ejemplo, agregando un comentario JS doc en público o puedes agregarlos a la configuración de ignorar de Knipp. Y luego los dejará en paz.

Pero creo que probablemente sea mejor simplemente escribir código que se use. Como PR probablemente debería ser unidades de trabajo aisladas. Y si siempre podemos ocultar cosas detrás de feature flags si no queremos mostrarlas a los clientes en una etapa temprana. Porque eventualmente comentarios como este evitarán que la función se limpie correctamente cuando realmente se vuelva inutilizada.

Ahora, otra cosa que he visto es la tendencia a simplemente escribir export delante de todo. Creo que AI hace esto. Y no sé si esto proviene de copiar y pegar o lo que sea. Pero siempre que tenemos un const o función exportada que solo se usa dentro del mismo archivo, Knipp lo reportará en CI. Y luego tienes que volver y arreglarlo y ejecutar CI nuevamente. Y todo esto crea una especie de ciclo de retroalimentación lenta, lo cual puede ser molesto.

Ahora, para abordar esto, hemos creado un hook opcional de pre-push al que los desarrolladores pueden optar si no quieren esperar a que CI termine. Pero también es bueno saber que Knipp ahora tiene un servidor de lenguaje que impulsa su servidor MCP, pero también integraciones de editor para VS Code y para IntelliJ. Así que ahora podemos obtener las líneas onduladas rojas directamente en nuestro código si una función exportada no se usa, lo que realmente puede ayudar con ese ciclo de retroalimentación lenta. Ahora, también quiero señalar que necesitamos ser un poco cuidadosos en bases de código que hacen muchas cosas dinámicas. Porque logré eliminar algo de código que probablemente no debería haber eliminado debido a algunas cosas que hacemos con require.context.

Así que require.context es una característica específica de Webpack que te permite buscar dinámicamente en un directorio e importar múltiples archivos con una expresión regular. Y luego Webpack convierte eso en alguna declaración require en tiempo de compilación. Ahora, en nuestros casos, estábamos cargando todos los formularios que tenemos. Y algunos de ellos aparecieron como no utilizados, así que los eliminé. Y no hubo error de tipo ni nada porque todo esto es enormemente dinámico. Los formularios simplemente faltaban en tiempo de ejecución. Así que revertimos eso y lo arreglamos.

Y la solución aquí fue agregar todo este directorio como un punto de entrada adicional a Knipp. Pero vale la pena señalar que no creo que este sea un gran patrón. No funciona bien para el análisis estático. Los desarrolladores tampoco pueden encontrar usos de estas cosas. Y en este momento estamos migrando a un nuevo sistema de formularios que utiliza 10-stick form. Así que con suerte este código desaparecerá pronto de todos modos.

Ahora, en general, hicimos más de 50 PRs en el transcurso de un par de semanas. Y pudimos eliminar casi el 3% de toda la base de código de Sentry, que son 28,000 líneas de código, lo cual creo que es una gran victoria. Pero la mayor victoria que tenemos ahora es ejecutar Knipp en CI, lo que evita que nuevo código muerto entre en la base de código. Porque de vez en cuando, encuentro un PR que reviso que tiene un chequeo de CI fallido donde Knipp encontró algo. Y luego hay otro commit que viene después de eso diciendo make Knipp happy o algo así. Y sí, eso también me hace feliz ver que no estamos obligados a hacer todas estas limpiezas sobre la marcha.

Así que si quieres probar Knipp, es tan fácil como ejecutar mpx-knipp en tu base de código. Ve hasta dónde puedes llegar sin ninguna configuración y probablemente te mostrará algunas cosas buenas. Y si tienes algunos falsos positivos, entonces simplemente ve y añade alguna configuración. Y luego puedes despejar tu base de código un Knipp a la vez. Gracias.

Así que una cosa que veo aquí son algunas preguntas sobre automatización y auto-merge en CI. Así que puedo simplemente resaltarlo en el tablero, en ese blanco. Así que mencionabas que integras esto en CI. Y veo auto-merge también. Así que tal vez eso sea algún tipo de automatización automática de todo el proceso de PR, también con tal vez algún tipo de revisión de IA o algo así del PR, para que las cosas simplemente se eliminen. ¿Y si las pruebas pasan, entonces todo está bien?

Así que lo que puedes hacer con Knipp es que tiene una bandera menos menos fix. Así que es auto-corregible en ese sentido. Si detecta cosas, puede eliminar automáticamente el código por ti. No hacemos eso, no porque no confíe en ello, principalmente porque creo que es divertido eliminar código. Así que es como una de las mejores partes del trabajo. Pero también, es bueno revisar las cosas solo porque podría haber falsos positivos. No confíes ciegamente en la herramienta. No es como un formateador. Si hay código que se elimina, sería bueno que hubiera un humano en el proceso, al menos. Pero es totalmente factible. Conozco personas que lo hacen y está bien.

Creo que si no tienes cosas dinámicas, lo peor que puede pasar es que Knipp elimine algo y luego obtengas un error de compilación en algún lugar y luego algo más se rompa en la pipeline. Pero técnicamente, debería estar totalmente bien ejecutar Knipp con menos menos fix en CI, como lo harías con tu formatter, como lo harías con ESLint, por ejemplo, si quieres hacer eso. Sí, está bien.

¿Y supongo que eso también lo hace recursivamente? Entonces, si elimina algo y luego eso, al eliminar eso, también algo más se vuelve eliminable, ¿entonces sigue ese camino recursivamente? Porque vi otra pregunta aquí. Es decir, ¿por qué Knipp no muestra todo para ser corregido en la primera ejecución? Sí. Creo que esa es una buena pregunta. Solo ve el código tal como está ahora. Entonces, para ver cómo sería el código después de haber eliminado las cosas, necesita eliminar primero y hacer una nueva ejecución. Y no creo que lo haga automáticamente.

Así que cuando lo ejecutas con menos menos fix, probablemente necesitarías ejecutarlo de nuevo hasta que obtengas cero errores por ti mismo. Está bien. Así que si ejecutaste fix varias veces, eventualmente, estaría claro. Podrías hacer un bucle en CI. Ahí lo tienes. Sí. Solo agrega más bucles, ¿verdad? Los bucles son la solución, he oído. Es tan de esta semana. Sí, esta es la última cosa. Solo escribe bucles. Ya no necesitas escribir ningún código. Otro es, así que no estoy seguro si esto está relacionado con la salida de Webpack. Así que veo algo aquí. ¿No están haciendo esto los bundlers como Webpack para la generación de chunks? Así que supongo que esta es la salida real de Webpack y los bundlers. ¿Está esto relacionado con lo que estás hablando principalmente? ¿O estás hablando más sobre el código fuente?

Entonces, lo que hacen los bundlers es que pueden hacer, los bundlers modernos pueden hacer tree shaking. Así que toman todos tus módulos fuente, los agrupan, los ponen en chunks separados, y luego básicamente sacuden el árbol para que caiga todo lo que no es necesario. Y eso funciona principalmente para el código que envías a los usuarios, por eso dije que ese código podría aumentar el tamaño de tu bundle. Si un módulo tiene un efecto secundario, no será eliminado por tree shaking. Si hay alguna mala configuración, o si usas un bundler más antiguo, podría no ser eliminado por tree shaking. Pero esa no es una de las principales razones.

Creo que la razón principal para no tenerlo es para que no tengas que mantenerlo. No tienes que actualizarlo. Y no tienes que asegurarte de que siempre compile con las últimas actualizaciones. No tienes dependencias que actualizas que podrían infectarse, aunque no las uses. ¿Verdad? Sí. Los ataques a la cadena de suministro son una realidad. He oído. Así que sí. Sí, es una cosa. Sí. Sí.

Así que no se trata solo de deshacerse del código para que tus usuarios tengan un tamaño de bundle más pequeño, sino también de todas esas otras cosas. Como no tener que mantenerlo y todo, simplemente no tenerlo en tu base de código en absoluto. Exactamente. Las cosas que no tienes, no tienes que preocuparte por ellas. Y no esperar que tu bundler las elimine correctamente. El mejor código es no tener código. Sí. Exactamente. Siempre ha sido así. Sí. Así que otra pregunta aquí es, ¿podría Knip usarse para limpiar otros tipos de cosas como localización, cadenas I18n? Supongo que eso es un poco más difícil porque necesita analizar diferentes tipos de uso, como también a nivel de cadena o algo así. No estoy seguro de qué, ¿tienes alguna idea o experiencia al respecto? Sí. Así que ahora mismo Knip solo recorre el AST y conoce sobre imports y exports.

Así que ahora mismo Knip solo recorre el AST y conoce sobre imports y exports. Y creo que ahí es donde se detiene. Pero una vez que tiene esa información, creo que teóricamente puede ir más allá y hacer otras cosas también. Como podría hacer detección de ciclos, podría hacer algunas otras cosas. Podría encontrar duplicados o complejidad y cosas así. Así que una vez que tienes ese, ese, ese, ese gráfico de imports, probablemente puedas poner algunos más pensamientos encima de eso. No sé cuáles son los planes en cuanto al futuro de Knip. Probablemente hablaré con Lars al respecto. Ya hay algunas otras herramientas que están surgiendo y que están yendo más allá de lo que Knip está haciendo. Así que creo que, especialmente debido al auge de la IA, tener herramientas que de alguna manera pongan las barreras alrededor de todo, creo que esas herramientas van a ser más ampliamente utilizadas.

Sí, totalmente. Creo que las barreras en el uso de la IA son algo importante porque todos están como ejecutándola autónomamente ahora y está arrasando con tu base de código. Y quieres tener al menos alguna idea de que las cosas no se van a romper demasiado. Sí. Aparte de Knip, ¿qué otras herramientas de limpieza o enfoques puedes, puedes recomendar? Como por ejemplo, está esta iniciativa E18E. Quizás algunos de ustedes han oído hablar de esto. Sí. ¿Hay algo, algo allí que te guste en esa iniciativa o alguna otra herramienta de limpieza que recomendarías? Sí. Así que el E18E es la Iniciativa de Rendimiento del Ecosistema. Y tendrías que hablar con James. Él está aquí en la conferencia. Y hablé con él antes. Tienen un gran plugin de ESLint, aparentemente, que aún no estoy usando. Así que lo estaré usando. Es el plugin de ESLint de E18E que puede, puede ayudar a encontrar dependencias de código que están ahí para pensar o fragmentos de código que podrían no estar funcionando, que pueden ser auto-corregidos a algunas otras cosas así. Definitivamente voy a, voy a, voy a revisar eso y probarlo.

Bien, genial. Así que tienes un plugin de ESLint para eso también. Bien, así que sí, eso puede ser algo que quieras revisar también. Veo algo aquí, ¿puedes usar Knip en poly repo? Así que no estoy seguro si poly repo se supone que es como tal vez mono repo o algo así.

No estoy seguro. O como, como un repo con múltiples paquetes en él o cosas así. Y luego si hay una pregunta de seguimiento, si se proporciona como entradas, así que estoy asumiendo que entonces cada paquete tendría sus propias entradas o algo así. Creo que entiendo la pregunta. Así que para un mono repo, es posible detectar entre paquetes. Así que puedes tener paquetes que tengan, como, usualmente tienen exports definidos que exponen cosas para que otros paquetes las usen. Y usualmente esos puntos de entrada no son revisados o no son verificados porque son consumidos por otros paquetes. Pero puedes configurarlo en un mono repo para que si el último uso en un paquete diferente se elimina, teóricamente también podrías eliminarlo del paquete fuente que lo tiene.

Si estamos hablando de múltiples repositorios que tienes, como por ejemplo, si tu sistema de diseño vive en un repositorio separado y luego tienes como múltiples otros repositorios que dependen de él, no creo que pueda llegar tan lejos porque en ese punto, esas cosas simplemente se convierten en otra dependencia de NPM y no vas a verificar los usos en, en todos tus node modules. Sí, ahí es donde se pone un poco más difícil, ¿verdad? Sí. Sí. De acuerdo.

También solo porque no está, está exportado desde tu sistema de diseño. No se usa en este momento no significa que quieras eliminarlo porque esos son como interfaces públicas que estás manteniendo cautelosamente y activamente. Sí. Así que no es como algo que se deja porque no quieres simplemente despublicar de NPM. Sí, exactamente. Sí.

Veamos. Tenemos, tenemos unos pocos, unos pocos minutos más aquí. ¿Hay espacio para que TypeScript y ESLint se vuelvan más capaces de soportar análisis entre archivos para que puedan hacer este tipo de optimizaciones de forma predeterminada? ¿Crees que este es el tipo de dirección hacia la que se dirigen esas cosas o es más como estas, estas deberían ser herramientas independientes? Creo que para TypeScript probablemente es una decisión consciente que no tocan cosas que están exportadas. Probablemente también para, para estas herramientas va a tomar un poco de, ya sabes, rendimiento para que, para que, para que entren en este análisis también. ESLint, no sé si podrían haberlo hecho. Creo que ESLint específicamente está destinado a linting cada archivo de forma aislada. Y luego está TypeScript ESLint que como que rompe esa suposición. Está ESLint import que también rompe esa suposición. Pero eso significa que no es tan fácilmente cacheable como las ejecuciones normales de ESLint. Así que hay compensaciones para todo eso. Y probablemente muchas cosas que ni siquiera sé. Así que creo que una herramienta que está hecha a medida para hacer un trabajo y que lo hace muy bien, creo que eso es un buen punto medio aquí.

OK, sí. Y otra es que funciona bien con, no sé si tienes alguna experiencia con esto, pero ¿funciona bien con frameworks full stack como Next.js o Remix o, o hay alguna limitación allí? Sí, lo hace. Lo que hace Knip es que tiene como, creo, 150 plugins. Y cada uno de estos plugins está hecho a medida para uno de esos frameworks o tecnologías. Y luego lo que hace es que se configura a sí mismo con entradas y proyectos porque conoce las, ya sabes, suposiciones que estos frameworks toman, o tal vez hay algunas convenciones de nomenclatura que estos frameworks tienen, que algunas cosas se llaman page.js y entonces Knip simplemente sabe sobre esto porque mira el package.js y ve, oh, estás usando estas tecnologías. Así que intenta configurarse a sí mismo en consecuencia. Sí. Y luego, sí, funciona muy bien en esos entornos también. Sí, eso tiene sentido. Así que, sí, creo que esa fue otra, otra pregunta que se me ocurrió es, ¿puede autoconfigurarse para un cierto, sí. Así que eso es. Puede, para la mayoría de las tecnologías también he contribuido como uno o dos de esos plugins. Si estás usando una tecnología que aún no está bien soportada, obviamente puedes configurar entradas de producto tú mismo, pero también puedes contribuir un plugin upstream y luego se incluirá. Y como cuando hice la masterclass por primera vez tenía como 130 plugins, ahora tiene 150 plugins. Así que es como, oh sí, el número siempre está aumentando. Está muy activamente mantenido. ¿Es 10 stack start también parte de eso o? Sí, lo es. Sí.

Genial. Impresionante. Veamos. Creo. Tal vez uno último aquí. Veamos. ¿Hay alguno? Oh sí. Creo que ya hablamos sobre el tema de la cascada, la cosa de la cascada. Pero tal vez, tal vez algo sobre falsos negativos. Si especificas incorrectamente los puntos de entrada, eso llevará a falsos negativos, supongo. ¿Verdad? Como si especificas algo que en realidad no debería ser un punto de entrada, entonces eso será en realidad código muerto que debería ser eliminado. Por ejemplo, tienes algún archivo en source o algo así, y esto se convierte en un punto de entrada, entonces no será reconocido. Eso es cierto.

Así que si tienes un directorio de scripts de source y lo pones como un punto de entrada, como script star dot star, lo que sea, ¿verdad? Todos mis scripts son puntos de entrada. Entonces, obviamente, si dejas de usar esos scripts, no serán reportados porque todos los archivos serán usados y serán vistos como puntos de entrada. Lo mismo que tenemos con los formularios. En realidad no sabemos qué formulario se usa o no porque es como si todos los directorios fueran solo un punto de entrada. Así que sí, intentaría que Knib se configure automáticamente con los plugins. Por supuesto. Y luego tratar de ser lo más específico posible cuando sobrescribas algunas de esas cosas. No incluir patrones glob muy amplios porque podrían incluir cosas como puntos de entrada que en realidad no deseas. Sí. Y eso evitará limpiezas adicionales. Sí. Sí. Bien. Genial. Bueno, sí. Aplaudan de nuevo para Dominic. Sí. Gracias.