El proyecto Taro (estilo VUE) agrega ganchos lint y git.

Antes de entender cómo lograr esto, es necesario que tengamos una definición clara y precisa de Lint. Wikipedia lo define de la siguiente manera:

En pocas palabras, Lint es una herramienta A. que analiza estáticamente el código e intenta identificar problemas potenciales, y usamos Lint para referirnos al proceso de uso de la herramienta en la práctica.

¿Cuáles son los beneficios de usar Lint? En mi opinión, existen al menos los siguientes tres puntos:

Se puede decir fácilmente que si no estás usando Lint, estás perdiendo tiempo y recursos del equipo.

Normalmente, en un proyecto VUE, el proyecto generado a través de @vue/cli instalará automáticamente las dependencias npm requeridas y generará los comandos eslint relevantes en package.json

Pero para VUE- proyectos de estilo basados ​​​​en Taro, también esperamos estandarizar el código antes de que los desarrolladores lo envíen a git-commit.commit), para evitar el problema de modificar constantemente el código para sazonarlo en el futuro.

Pero @tarojs/cli no instala automáticamente las bibliotecas npm requeridas al crear el proyecto como lo hace @vue/cli, y no genera los comandos correspondientes en package.json.

Entonces, ¿cómo configuramos los activadores de detección de flujo de trabajo de eslint y git en el proyecto taro?

Primero, configuramos el propio eslint.

Las siguientes son las dependencias de npm que necesitamos instalar:

Después de instalar estas reglas, generalmente podemos realizar una inspección de código en el proyecto vue generado por taro. A continuación, si necesitamos configurar la aplicación de las reglas de eslint, modifique el archivo .eslintrc.js en el directorio raíz del proyecto.

Dado que necesitamos aplicar las reglas al archivo vue, debemos agregar el atributo extends en el archivo .eslintrc.js:

Para obtener más detalles, consulte mit, etc. ., y luego git ejecutará el gancho correspondiente.

Más tarde, cuando ejecute el comando de confirmación de git, git ingresará el enlace de confirmación previa.

El contenido de ejecución del gancho generalmente se configura en package.json. Veamos cómo se configura en el proyecto rivendell:

lint-staged

. lint-staged

Ahora, si ejecutamos git, git ejecutará el gancho y git ejecutará el gancho. p> Ahora, si hacemos un compromiso de git, el gancho de git ejecutará automáticamente el comando, pero en este momento puede recibir un mensaje de error (o en el proyecto vue, como una dependencia instalada) que le indica que necesita instalar lint -staged, así que veamos qué hace lint-staged.

Si ejecuta eslint antes de cada confirmación para detectar problemas con las reglas del código en todos los archivos, y si el código activa un estilo de código que no está permitido por las reglas, generará todos los problemas:

Puedes ver que si el proyecto no ha sido probado con estilo de código, detectará más de 10,000 errores de pelusa a la vez

Incluso si el proyecto es un proyecto con estilo de código probado, cuando envíes tu Cuándo Cuando codificas, también se informarán problemas de pelusa en el código de otras personas, lo que te impedirá enviar tu propio código, lo que puede resultar molesto. Por lo tanto, agregar la capacidad de rellenar la preparación cuando todos tienen una nueva confirmación y realizar revisiones de código solo en el código modificado resolvería este problema.

El ingeniero de Feedly, Andrey Okonetchnikov, desarrolló lint-staged basándose en esta idea. Staged es un concepto en Git que se refiere al área a enviar. Cuando usas git commit -a o git add, tus cambios son. Pasó por el área pendiente y luego se comprometió a través del área de preparación.

Así es como funciona lint-staged:

Primero, instale las dependencias:

Luego, modifique la configuración de package.json para agregar las siguientes entradas:

p>

En las primeras etapas de un proyecto 0 a 1, es posible que no tengamos la energía para concentrarnos en el estilo de codificación y el buen formato. Sin embargo, un estilo de codificación deficiente puede ocultar muchos errores que no son fáciles de encontrar y causar muchos problemas a los estudiantes que se hagan cargo de la modificación en el futuro.

Los archivos de código mal formateados pueden confundir a los lectores y también a los modificadores que no pueden entender la lógica.

La persona que tome el relevo puede que dentro de unos meses sea yo.

Por lo tanto, mejorar la especificación y el formato de su código no es una pérdida de tiempo, sino una forma de salvarle la vida en el futuro.

Salvar tu vida también salva la vida de los demás.