La calidad ante todo 5 sencillos pasos para eliminar la pelusa de su código con flujos de trabajo de GitHub en el proyecto JavaScript

¿Qué debemos hacer cuando el proyecto es pequeño o el cliente aún no sabe si merece la pena invertir más? Obviamente, en el Fase MVP del proyecto, código El estilo o las pruebas unitarias no son la máxima prioridad. Los inversores suelen querer tener un buen producto y vamos, si funciona, no hace falta probarlo, ¿no?

En realidad, tengo algo de experiencia en crear aplicaciones desde ceroincluso sin utilizar las mejores prácticas. Algunas circunstancias empresariales me obligaron a buscar el compromiso entre los planes presupuestarios de un inversor y la lista de "cosas bonitas" del desarrollador. Por suerte, si utilizas GitHub, la mayoría de los problemas habituales relacionados con la calidad del código pueden resolverse en unos minutos.

En este artículo, voy a mostrarte cómo utilizar los flujos de trabajo de GitHub en el entorno Node.js para estandarizar tu código base.

Algunas suposiciones antes de empezar:

• Está familiarizado con NPM y la consola Linux.
• Tienes alguna experiencia con preprocesadores de estilo, cargadores de módulos, bundlers, etc.
• Ya sabe para qué sirven los linters y tiene muchas ganas de utilizarlos en sus proyectos.

1. Estructura típica de un proyecto JavaScript

Si alguna vez has utilizado frameworks JS como Vue o React, puede detectar fácilmente algunas cosas comunes entre ellos, p. ej:

• /src con toda su lógica JS y componentes,
• /prueba para las pruebas unitarias y e2e,
• /activos para estilos, imágenes, etc.

Aunque estemos hablando de JavaScript proyecto, trabajamos en Nodo así que, obviamente, también debería haber algunas cosas de Node como paquete.json, paquete-lock.json y /node_modules en nuestro directorio raíz.

Todas estas cosas están en su sitio - eso es lo que llamamos el convención. Los frameworks se inventan para proporcionar algunas convenciones razonables, por lo que normalmente, ni siquiera necesitamos preocuparnos por el patrón de diseño inicial. Como en este ejemplo, quiero explicar algunos enfoques, no voy a aplicar ninguna solución lista para usar como Vue CLI.

Es hora de entender qué se esconde bajo todos estos guiones mágicos de pelusa.

2. Ampliación del típico proyecto Node

Para proporcionar soluciones de alta calidad, los linters son lo primero con lo que debemos empezar al configurar un nuevo proyecto. Centrémonos en dos linters - Stylelint para estilos (*.scss) y ESLint para archivos fuente (*.js). Ambos linters están disponibles en NPM y son bastante fáciles de configurar. Usar linters requiere pasar por el proceso de instalación, añadir archivos de configuración y definir scripts de proyecto. Hagámoslo paso a paso.

3. Añadir Stylelint

La instalación de Stylelint en el entorno Node es realmente sencilla. Según documentos oficialesSólo tienes que correr:

npm install --save-dev stylelint stylelint-config-standard

y esperar a que termine.

stylelint-config-standard proporciona un conjunto predeterminado de reglas de linting y puede sustituirse por cualquier paquete que se adapte mejor a sus necesidades (p. ej. Al estilo Airbnb). A continuación, cree un nuevo archivo oculto .stylelintrc.jsonque es el archivo de configuración de Stylelint, responsable de cargar nuestras reglas predefinidas:

{
    "extends": "stylelint-config-standard"
}

Ahora mismo, lo único que falta es algún script NPM (o scripts) declarado en el archivo package.json para empezar a linting nuestros archivos SCSS. Esta es mi propuesta:

"scripts": {
    "lint:scss": "stylelint '**/*.scss' --syntax scss -f verbose --color",
    "lint:scss:fix": "stylelint '**/*.scss' --sintaxis scss --fix -f verbose -color"
}

Como puedes ver, he declarado el script que contiene -fijar Esta opción se utiliza antes de enviar los cambios al repositorio.

Recuerde: es una mala práctica utilizar -fijar en tu flujo de CI, porque entonces el código que pasas a producción no tiene el estilo correcto en el repositorio. Por eso necesitamos los dos guiones.

Vamos a probar nuestro linter creando un fichero /activos/scss/estilos.scss con algún contenido, como:

cuerpo {
                    color de fondo: #fff;
}

npm run lint:scss

Deberías ver en tu consola algo como esto:

> stylelint '**/*.scss' --syntax scss -f verbose --color

assets/scss/styles.scss

2:21 ✖ Sangría esperada de 2 espacios sangría

1 fuente comprobada

~/Codest/Projects/github-workflow-demo/assets/scss/styles.scss

1 problema encontrado

nivel de gravedad "error": 1

sangría: 1

npm ERR! code ELIFECYCLE

npm ERR! errno 2

npm ERR! [email protected] lint:scss: `stylelint '**/*.scss' --syntax scss -f verbose --color`

npm ¡ERR! Estado de salida 2

Esto significa que nuestro linter funciona.

La salida muestra exactamente qué línea causa un error y describe el problema a resolver. Algunos problemas no se pueden solucionar automáticamente, ya que necesitan la decisión de un desarrollador, pero en la mayoría de los casos, basta con ejecutar el mismo comando con -fijar así que vamos a ejecutarlo.

npm run lint:scss:fix

Ahora debería ver una salida verde sin errores encontrados:

stylelint '**/*.scss' --sintaxis scss --fix -f verbose --color


1 fuente comprobada

/Users/wojciechbak/Codest/Projects/github-workflow-demo/assets/scss/styles.scss

0 problemas encontrados

4. Añadir ESLint

Este paso es casi el mismo que el anterior. Vamos a instalar ESLint, definir un conjunto de reglas por defecto y declarar dos scripts NPM invocables - uno para CI, otro para pre-push. ¡Vamos a ir a través de esto!

Si utilizas NPM en tu trabajo diario, quizás quieras instalar ESLint de forma global. Si no es así, consulte las instrucciones de instalación en documentos oficiales.

npm install -g eslint

Cuando el comando eslint esté disponible en su máquina, simplemente ejecútelo en su proyecto:

eslint --init

Siguiendo las instrucciones que aparecen en tu terminal, sólo tienes que tomar algunas decisiones de proyecto como:

• Javascript o TypeScript
• Al estilo Airbnb o al estilo Google
• tipo de configuración (archivo JSON, archivo JS o inline en paquete.json)
• Módulos ES (importación/exportación) o requiere sintaxis

En este lugar vale la pena escribir unas palabras sobre el formateador de código llamado Prettier. Está totalmente estandarizado y es compatible con la mayoría de los editores de código (por ejemplo, VS Code). Prettier proporciona muchos conjuntos de reglas predefinidas de estilo de código, trabaja con linters y puede ser un gran apoyo en la búsqueda de la máxima calidad del código. Para saber qué es exactamente Prettier, visite este enlace comparación de los documentos oficiales.

Si se hace, el archivo de configuración de ESlint (p.ej. .eslintrc.jsondependiendo de lo que hayas elegido antes) debería aparecer en tu directorio raíz, en algún lugar junto a .stylelintrc.json creado antes.

Ahora tenemos que definir scripts en paquete.json igual que para los archivos SCSS:

"scripts": {
    "lint:js": "eslint '**/*.js' --ignore-pattern node_modules/",
    "lint:js:fix": "eslint '**/*.js' --ignore-pattern node_modules/ --fix"
}

¡Enhorabuena! ESLint está listo para usarse ahora mismo. Comprobemos si funciona correctamente. Crear /src/index.js con algún contenido:

console.log("algo");

Ejecutar linter:

npm run lint:js


El resultado debería ser el siguiente:

> eslint '**/*.js' --ignore-pattern node_modules/

~/Codest/Projects/github-workflow-demo/src/index.js

1:1 warning Declaración de consola inesperada no-console

✖ 1 problema (0 errores, 1 advertencia)

Esta advertencia no desaparecerá después de utilizar -fijar porque linters no afecta al código potencialmente significativo. Sólo sirven para estilizar el códigoincluyendo espacios en blanco, nuevas líneas, punto y coma, comillas, etc.

5. Definición de flujos de trabajo de GitHub

Flujos de trabajo de GitHub son algo bastante bien documentado. Siéntase libre de profundizar en esto, pero por ahora, voy a implementar un flujo de trabajo simple para pelusa nuestro código después del empuje al repositorio remoto (obviamente, alojado en GitHub).

Cree /.github/workflows y el nuevo calidad del código-workflow.yml ya que los flujos de trabajo de GitHub deben definirse con archivos YAML.

Para ejecutar un flujo de trabajo adecuado, tenemos que responder a algunas preguntas:

• ¿Cuándo queremos ejecutar nuestro flujo de trabajo (en push, en pull request, en merge, etc.)?
• ¿Queremos excluir algunas situaciones (como push to branch master)?
• ¿Qué entorno debemos configurar para ejecutar correctamente nuestros comandos (en este ejemplo, Node)?
• ¿Necesitamos instalar dependencias? En caso afirmativo, ¿cómo debemos almacenarlo en caché?
• ¿Qué pasos debemos dar para completar la comprobación?

Después de algunas consideraciones y algunas horas de trabajo con docs ejemplo .yml puede tener este aspecto:

nombre: Calidad del código

on: 'push

trabajos:
  calidad del código:
    nombre: Lint source code
    se ejecuta en: ubuntu-latest
    pasos:
    - usa: actions/checkout@v1

    - nombre: Setup Node
      usa: actions/setup-node@v1
      con:
        node-version: '12.1'

    - nombre: Cache dependencies
      usa: actions/cache@v1
      con:
        ruta: ./node_modules
        key: $(( runner.OS ))-dependencies-$(( hashFiles('**/package-lock.json') ))
        restaurar-llaves: |
          $(( runner.OS ))-dependencias-$(( env.cache-name ))-
          $(( runner.OS ))-dependencias-
          $(( runner.OS ))-dependencias-

    - nombre: Instalar dependencias
      ejecutar: |
        npm install

    - nombre: Lint files
      run: |
        npm run lint

GitHub proporciona todo el material ambiental que necesitamos. En la última línea estamos ejecutando el comando npm run lint que antes no estaba definido:

"scripts": {
    "lint": "npm run lint:js && npm run lint:scss"
}

Tenga en cuenta que en nuestro flujo de trabajo no estoy usando :arreglar comandos.

Una vez realizados todos estos pasos, puede disfrutar de este hermoso resultado de GitHub antes de fusionar su Pull Request: