Depurar los repositorios de clientes

Tabla de contenidos

• Knip
  • Configuración
  • Analizar un repositorio
  • Ejemplo de falsos positivos en exportaciones sin usar
  • Ejemplo de exportaciones reportadas como duplicadas que en realidad no causan problemas
  • Ejemplo de falso positivo en dependencias sin usar
• Aplicar cambios de paquetes manteniendo las instalaciones locales limpias y coherentes
  • ¿Por qué evitar editar manualmente package.json (salvo cuando no es posible)?

Knip

Knip es útil para identificar dependencias no listadas, exportaciones duplicadas y archivos, dependencias o exportaciones potencialmente sin usar.

¡Cuidado con los falsos positivos!

Evite implementar a ciegas todo lo que se reporta. Observe, verifique y pruebe. Haga sus propias búsquedas y reflexiones para cosas como las exportaciones reportadas como sin usar.

Knip no está destinado a resource-core, webfonts-core, pankosmia-web ni desktop-app-*.

Es para proyectos construidos con un packages.json y un index.js, que utiliza para recorrer y evaluar todos los includes de la aplicación.

Configuración

npm install -g knip (para instalar o actualizar)

Analizar un repositorio

En la raíz del repositorio del cliente en un terminal, escriba knip. Proporcionará una lista de cualquier elemento sin usar, no listado o duplicado que sospeche haber encontrado.

Ejemplo de falsos positivos en exportaciones sin usar

Reportará Selection.styles.jsx como una exportación sin usar (debido al nombre del archivo) incluso cuando está en uso. Tenga cuidado de no eliminar este archivo cuando su exportación está realmente en uso.

Ejemplo de exportaciones reportadas como duplicadas que en realidad no causan problemas

Selection.styles.jsx exporta sx, lo cual funciona bien tal como se usa.

Ejemplo de falso positivo en dependencias sin usar

Knip es bastante bueno siguiendo la cadena de includes a lo largo de un proyecto. Sin embargo, a veces hay dependencias fuera de esta cadena, que no detectará. Por ejemplo, si un package.json incluye el uso de react-scripts en su sección de scripts, su cadena de dependencias incluye babel, que incluye una devDependency de @babel/plugin-proposal-private-property-in-object. Knip pasará por alto ese caso y lo reportará como una dependencia sin usar, pero en ese caso en realidad sí se usa.

Aplicar cambios de paquetes manteniendo las instalaciones locales limpias y coherentes

• Use npm ci. Esto elimina node_modules y coincide con el archivo de bloqueo.
• Para actualizar la versión de un paquete, siga npm ci con npm install <package_name>@0.1.29 --save-exact
• Para eliminar un paquete, siga npm ci con npm uninstall <package_name>
• Para agregar un paquete, siga npm ci con npm install <package_name> --save-dev o npm install <package_name> -D (para devDependencies) o npm install <package-name> --save-optional

¿Por qué evitar editar manualmente package.json (salvo cuando no es posible)?

npm i tiende a generar diferencias en package-lock.json según el sistema operativo y no mantiene node_modules limpio. Tenga en cuenta también que, tras una edición manual de package.json, ejecutar npm prune no actualiza package-lock.json para reflejar la eliminación, y no desinstala los scripts de ciclo de vida (que permiten a los paquetes realizar acciones personalizadas automáticamente).