¿Por qué necesitamos instalar eslint por separado como paquete npm y extensión vscode?

Respuesta corta: no lo haces.

Respuesta larga:

La instalación de ESLint/Prettier como extensión le permite formatear/verificar su código dentro del VSCode.

Sin embargo, instalarlos también como dependencias trae beneficios adicionales:

• VSCode utilizará exactamente el mismo paquete que el instalado. Por lo tanto, no detectará la situación cuando VSCode dice OK, pero su servidor CI dice: NO OK
• Obtendrá el control sobre las versiones y podrá actualizar cuando lo desee.
• Podrá utilizar diferentes versiones para diferentes proyectos. Esto es especialmente importante cuando no puede migrar un proyecto antiguo, pero desea utilizar las últimas posibilidades para el nuevo.
• Podrá acceder a Prettier/ESlint a través del bloque de secuencias de script de package.json y podrá escribir comandos personalizados con parámetros exactamente como los necesita.
• Podrá emparejarlos con ganchos Husky o NPM para verificar/formatear automáticamente el código

Según mi experiencia, si puede instalar algo localmente, instálelo como dependencia del paquete (excepto CLI como create-react-app o angular-cli que lo ayuda a iniciar la aplicación). Esto hará que tu vida sea un poco predecible.

Estos programas pueden formatear su código (ESLint y Prettier) y detectar una sintaxis específica (ESLint).

Cuando se instala como una extensión en su IDE (vscode por ejemplo), puede obtener:

• líneas onduladas en tiempo real;
• y formatear al guardar.

Pero es posible que alguien que inicie su proyecto en su propio entorno no tenga estas extensiones instaladas (es posible que ni siquiera tenga el mismo IDE) y, por lo tanto, es posible que no las obtenga.

Cuando se instalan como paquetes npm (y se incluyen en algún lugar de la canalización, ya sea en el inicio de npm, en su implementación continua, o...)

• no obtendrá líneas onduladas en tiempo real,
• pero aún puede obtener el formato automático (aunque no necesariamente al guardar, según la configuración),
• puede obtener reglas de bloqueo (es decir, en lugar de solo ver errores/advertencias, puede bloquear las canalizaciones hasta que el desarrollador corrija dichos errores/advertencias)
• puede asegurarse de que cualquiera que inicie el proyecto, desde cualquier IDE, obtenga los paquetes incluidos