1. En desarrollo: Usamos un visualizador de errores como un middleware de error modal + consola/registrador de errores.
2. En puesta en escena y producción: solo usamos un visualizador de errores como modal porque nunca esperará que un usuario o un probador de caja negra del equipo (en caso de probar la implementación de la puesta en escena) vaya a la consola Entonces, ¿de qué sirve consolar? ¿en producción? Tenga en cuenta que consolar en producción podría incluso ser una fuga para que los piratas informáticos sepan vívidamente lo que está sucediendo. Por lo tanto, sugeriré nunca consolar en la puesta en escena/producción, porque cualquier cosa que llegue a la puesta en escena significa que llegará a la producción una vez que termine la prueba (por lo que la producción y la puesta en escena tienen las mismas reglas).

Entonces, sobre la cosa de Eslint, le sugiero que la apague en el archivo de eslint, y sea consciente de la regla de no poner una consola innecesaria. Para mí, lo que hago antes de enviar el código para la solicitud de extracción es hacer: SHIFT + CTRL+ F y luego escribir "console.log" para saber qué archivos tienen el método console.log en mi VS-CODE y luego los elimino.

No podemos dejar que un linter decida todo por nosotros, recomendaría dejar el error de console.error porque en la mayoría de los casos necesitamos ver estos errores en la consola y leerlos, existen por una razón.

Y para el estilo de escritura, por supuesto, podemos usar el estilo point free

 .catch(console.error)

Y para el linter, lo más probable es que tenga una regla (en su documentación) para silenciar ese error.