Mi aplicación de reacción se inicia con CRA (react-scripts v4.0.0) y quiero agregar un formateador de código (más bonito para ser específico) que debe formatear el código antes de confirmar los cambios en mi repositorio de git.
Sé que eslint es una dependencia de los scripts de reacción y el linting se realiza usando 'eslint-webpack-plugin' (habilitado por defecto) dentro de la configuración del paquete web. Fragmento de CRA github | Configuración del paquete web React Scripts
Ahora, si quiero extender mi eslint-config original, puedo instalar/escribir un nuevo eslint-config como 'eslint-config-prettier' y agregarlo a mi clave extendida dentro de eslint-config. Y esto haría el trabajo.
Suponiendo que esto actualice la configuración actual de eslint sin instalar ninguna dependencia adicional y, como es normal, borraría el código de la aplicación cada vez (con la configuración actualizada) cuando se cambie el código. Y arrojaría errores de compilación como debería.
He visto varios tutoriales sobre la instalación web de eslint nuevamente como una dependencia de desarrollo y luego lo uso dentro de ganchos de compromiso previo para solucionar problemas de pelusa y luego ejecutar los formateadores de código como más bonitos secuencialmente después de eso. ¿Es necesario instalar y ejecutar eslint --fix en un enlace previo a la confirmación? o es redundante?
Incluso si la aplicación de reacción basada en CRA detiene la compilación en caso de error de pelusa, no evita estrictamente que el usuario cometa el código incorrecto.
Agregar el gancho de confirmación previa eslint --fix detiene la confirmación del usuario si hay un error de pelusa irreparable presente en los archivos preparados o en todo el proyecto (según el comando, el patrón global de archivos proporcionado), por lo que evita la inserción accidental de código incorrecto.
Sin embargo, instalar eslint nuevamente en caso de CRA es redundante ya que ya está presente como una dependencia para los scripts de reacción.
