Spectral es un linter de JSON/YAML con énfasis en las especificaciones OpenAPI y AsyncAPI. Incluye un amplio conjunto de reglas para dichas especificaciones, que pueden evitar dolores de cabeza a los desarrolladores al diseñar e implementar APIs o colaboración orientada a eventos. Estas reglas comprueban que las especificaciones de los parámetros de la API sean correctas o la existencia de una declaración de licencia en la especificación, entre otras cosas. El CLI facilita incorporar Spectral tanto en el desarrollo local como en los pipelines de CI/CD y la API JavaScript soporta casos de uso más avanzados. El sitio de GitHub enlaza a conjuntos de reglas del mundo real disponibles de manera pública por compañías como Adidas, ayudando a que los equipos puedan adoptar sus propias reglas de linting.
Uno de los patrones que hemos visto repetirse en esta publicación es que las herramientas estáticas de comprobación de errores y estilo surgen rápidamente después de que un nuevo lenguaje gana popularidad. Estas herramientas se conocen genéricamente como linters, en honor a la clásica y querida utilidad lint de Unix, que analiza estáticamente el código C. Nos gustan estas herramientas porque detectan errores tempranamente, incluso antes de que se compile el código. La instancia más nueva de este patrón es Spectral, un linter para YAML y JSON. Aunque Spectral es una herramienta genérica para estos formatos, su principal objetivo es OpenAPI (la evolución de Swagger) y AsyncAPI. Spectral viene con un conjunto completo de reglas listas para usar para estas especificaciones que pueden ahorrarle dolores de cabeza a las personas desarrolladoras al diseñar e implementar APIs o colaboración basada en eventos. Estas reglas verifican las especificaciones adecuadas de los parámetros de la API o la existencia de una declaración de licencia en la especificación, entre otras cosas. Si bien esta herramienta es una adición bienvenida al flujo de trabajo de desarrollo de APIs, plantea la pregunta de si una especificación no ejecutable debe ser tan compleja como para requerir una técnica de verificación de errores diseñada para lenguajes de programación. ¿Quizás las personas desarrolladoras deberían escribir código en lugar de especificaciones?
