Standard JS – Automatizando el proceso

Como buenos programadores siempre vamos a buscar la manera de automatizar esos procesos repetitivos y tediosos que no aportan nada y solo nos toman tiempo y suponen una fuente de error humano. Para realizar el chequeo de Standard de manera automática vamos a presentar 2 maneras que pueden resultar interesantes. 

Package.json script

La primera requiere modificar el archivo package.json de nuestro proyecto incluyendo un script como lo hacemos para debuggear o testear el código. 

Basta con incluir standard en el script de testeo como se muestra a continuación:

{
  "name": "Some cool project",
  "version": "1.0.0",
  "description": "Klooid blog example",
  "main": "server.js",
  "scripts": {
    "test": "NODE_ENV=test mocha --exit test/test && standard",
    "standard": "standard",
    "start": "node server.js",
    "debug": "nodemon server.js"
  },

   "devDependencies": {
    "babel-eslint": "^10.1.0",
    "standard": "^16.0.3"
  },
  "standard": {
    "env": [
      "mocha"
    ],
    "parser": "babel-eslint"
  }
}

En la sección de scripts tenemos 2 scripts interesantes de analizar. Al primero le llamamos test donde le indicamos a Node que estamos en un ambiente de pruebas, corremos las pruebas que escribimos para nuestro código y además chequeamos el estilo de Standard. En caso que no estés desarrollando pruebas en tu código, lo cual no te recomendamos hacer, puedes utilizar simplemente el segundo script standard en donde simplemente se chequea el estilo de Standard. 

También vale la pena hablar de la última sección del código, en Klooid, Mocha es comúnmente utilizado para realizar pruebas al código. Mocha es un marco de prueba de JavaScript para programas Node.js, que ofrece compatibilidad con navegadores, pruebas asincrónicas, informes de cobertura de pruebas y uso de cualquier biblioteca de aserciones. Para utilizar la guía de Standard en nuestras pruebas instalamos el parser de babel-eslint y le indicamos que lo utilice cuando se encuentre en el ambiente de Mocha.

La otra manera en la que podemos automatizar el proceso de chequeo de la guía de Standard es utilizando GitHooks. 

GitHooks

Como muchos otros sistemas de control de versiones, Git tiene una forma de ejecutar scripts personalizados cuando ocurren ciertas acciones importantes. Hay dos grupos de estos hooks: del lado del cliente y del lado del servidor. Los hooks del lado del cliente se activan mediante operaciones como commit y merge, mientras que los hooks del lado del servidor se ejecutan en operaciones de red como la recepción de commits después de un push.

Cuando inicializamos un repositorio con git automáticamente se crean dentro de .git/hooks una serie de ejemplos o muestras de algunos hooks que podemos utilizar. 

La lista completa de hooks que podemos configurar:

• applypatch-msg
• pre-applypatch
• post-applypatch
• pre-commit
• prepare-commit-msg
• commit-msg
• post-commit
• pre-rebase
• post-checkout
• post-merge
• pre-receive
• update
• post-receive
• post-update
• pre-auto-gc
• post-rewrite
• pre-push

Para revisar el estilo de nuestro código antes de hacer un commit podemos utilizar un hook pre-commit. El siguiente extracto de codigo fue tomado de la pagina oficial de Standard:

#!/bin/bash
function xargs-r() {
  # Portable version of "xargs -r". The -r flag is a GNU extension that
  # prevents xargs from running if there are no input files.
  if IFS= read -r -d $'\n' path; then
    echo "$path" | cat - | xargs "$@"
  fi
}
git diff --name-only --cached --relative | grep '\.jsx\?$' | sed 's/[^[:alnum:]]/\\&/g' | xargs-r -E '' -t standard
if [[ $? -ne 0 ]]; then
  echo 'JavaScript Standard Style errors were detected. Aborting commit.'
  exit 1
fi

Una alternativa a GitHooks corresponde al paquete de npm pre-commit. Con este podemos manejar todas las pruebas que queramos realizar a nuestro código antes de hacer un commit utilizando un archivo .pre-commit-config.yaml. La ventaja de este método es que fácilmente se comparten las configuraciones de nuestros archivos de pre-commit con el resto del equipo.

Conclusión

A la hora de escribir código es importante tomar en cuenta aspectos más allá de la funcionalidad del mismo. Mantener un mismo estilo dentro de un equipo de trabajo nos va a ahorrar tiempo y discusiones innecesarias, además, nos va a permitir colaborar en la comunidad de código abierto más fácilmente. Standard Js es solo uno de muchos estilos que existen, así que si programas en otro lenguaje vale la pena tomarse el tiempo de investigar cuáles guías de estilo se están siguiendo actualmente e incorporarlas al desarrollo diario. En Standard Js con 2 simples scripts podemos chequear que se cumplan las reglas de la guía y además corregir los errores que encontremos de manera fácil y rápida. Y finalmente si sos de esas personas que les gusta automatizar esos procesos repetitivos y tediosos puedes hacer uso de un GitHook para nunca más tener code reviews de estilo.