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

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 o npm install --global 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

Migración de npm a pnpm en proceso

Usa el archivo de bloqueo en la raíz del repositorio para determinar cuál aplica: pnpm-lock.yaml → pnpm; package-lock.json → npm. Para más detalles, consulta nuestro Plan de migración.

	pnpm-lock.yaml	package-lock.json
Use	pnpm install o edita manualmente package.json y luego ejecuta pnpm i	npm ci. Esto elimina node_modules y coincide con el archivo de bloqueo.
Para actualizar la versión de un paquete, siga pnpm i/npm ci con:	pnpm i <package_name>@0.1.29 --save-exact o edita manualmente package.json y luego ejecuta pnpm i	npm i <package_name>@0.1.29 --save-exact
Para eliminar un paquete, siga npm ci con:	pnpm uninstall <package_name> o edita manualmente package.json y luego ejecuta pnpm i	npm uninstall <package_name>
Para agregar un paquete, siga pnpm i/npm ci con:	pnpm i <package_name> --save-dev o pnpm i <package_name> -D (para devDependencies) o pnpm add <package-name> -O o edita manualmente package.json y luego ejecuta pnpm i	npm i <package_name> --save-dev o npm i <package_name> -D (para devDependencies) o npm i <package-name> --save-optional