Comparación de bibliotecas de creación de CLI

Nexmo dispone de una CLIque utilizamos como alternativa al Dashboard. Te permite administrar tu Account de Nexmo y usar los productos de Vonage desde la línea de comandos. Hemos tenido esta herramienta durante unos 4 años, y está escrita en Node.js.

La semana pasada Escribí acerca de por qué estamos tomando el tiempo para reescribirloy compartí un poco sobre el proceso que estamos utilizando para reescribir el Nexmo CLI.

Hoy voy a entrar en más detalles, compartir los marcos que analizamos y los criterios que utilizamos para hacerlo. También voy a mostrar algunos pros y contras de los que elegimos para construir nuestras pruebas de concepto con.

Criterios de referencia

Después de realizar una retrospectiva interna de nuestra CLI e identificar una serie de requisitos, elaboramos una lista de comandos de ejemplo. Estos comandos nos ayudaron a establecer una serie de criterios para evaluar las bibliotecas utilizadas para crear interfaces de línea de comandos. Nuestros criterios buscaban responder a algunas preguntas:

• ¿Qué idioma admite la biblioteca?

• ¿Se mantiene activamente?

• ¿Admite subcomandos? Por ejemplo nexmo app list

• ¿Es compatible con varios formatos de salida?

• ¿Dispone de un mecanismo de complemento?

• ¿Pueden los comandos tener varios alias?

• ¿Puede generar binarios?

• ¿Cómo es la gestión de la configuración?

• ¿Es multiplataforma?

• ¿Tiene autocompletar comandos?

• ¿Puede tener comandos interactivos?

• ¿Podemos definir banderas globales?

Armados con esta lista de preguntas candentes, nos pusimos a buscar el mayor número posible de bibliotecas de creación de CLI que cumplieran la mayoría de los requisitos y marcaran sus características según nuestra lista de criterios de calificación. Al final lo redujimos a seis bibliotecas, para JavaScript, TypeScript y Go, basándonos en las habilidades lingüísticas disponibles en el equipo: oclif, gluegun, ink, caporal, cli y cobra.

Comparación de funciones

Revisamos la página de inicio de cada marco y nos fijamos en las características que soportaba, creando una matriz de análisis. Utilizamos ❎ para significar que el framework tiene soporte completo para esa característica, ❎ para significar que el framework no soporta esa característica y ✳️ que sólo había soporte parcial. Así es como quedó nuestra matriz para los 6 marcos que identificamos:

Al examinar la lista de características, no pudimos identificar un claro ganador, sobre todo porque aún quedaban algunas incógnitas. Así que decidimos elegir tres frameworks y crear una prueba de concepto con cada uno de ellos.

PdC

Nuestra primera elección para construir una prueba de concepto fue oclif. La razón principal por la que lo elegimos fue porque parecía cumplir la mayoría de nuestros requisitos, algunos incluso dos veces (tenía soporte para plugins y un plugin con el que crear plugins).

La segunda elección fue caporal porque la biblioteca parecía razonablemente similar a nuestro framework actual, commander. Esto significaría que la curva de aprendizaje y el tiempo necesario para reescribirlo habrían sido considerablemente menores.

Finalmente, nuestra última elección para la prueba de concepto fue inky la elegimos porque cumplía los requisitos suficientes para que mereciera la pena y tiene un enorme ecosistema detrás.

Una vez identificados los marcos de trabajo, nos planteamos el alcance de la prueba de concepto. Queríamos algo representativo de la CLI final en lugar de construir un Hello World ejemplo. Al mismo tiempo, tenía que ser lo suficientemente pequeño como para que no nos sintiéramos mal tirando la prueba de concepto al final de este ejercicio. Aterrizamos en la construcción de la actual nexmo setup y nexmo number:list comandos. Eso significaba que podíamos probar banderas globales, gestión de configuración, subcomandos, formatos de salida, interactividad, y varios marcos de lenguaje.

Elección de la próxima biblioteca de construcción CLI

Lorna, Dwane y yo mismo elegimos cada uno uno de los tres frameworks y empezamos a construir nuestras pruebas de concepto. Una vez que terminamos, mostramos algunos de los pros y los contras de trabajar con cada biblioteca y cómo eso se relaciona con algunos de nuestros otros requisitos.

Caporal

Lorna construyó el caporal PdC. La mayor ventaja era que era posible migrar nuestra CLI actual de commander a caporal sin necesidad de reescribirla por completo. Eso nos ahorraría bastante tiempo.

Los contras eran en su mayoría similares a nuestras commander y el proyecto no se mantiene tan activamente como nos hubiera gustado. Probablemente tendríamos que bifurcar el proyecto y mantener una comunidad en torno a él, lo que anularía parte de la velocidad que ganaríamos si no tuviéramos que reescribir. También significaría que algunos de nuestros requisitos, como los plugins, tendrían que crearse desde cero.

Tinta

Dwane construyó el ink PoC. La mayor ventaja era que usaba React como framework, que trae consigo una comunidad y un ecosistema masivos. Tenía un montón de plugins disponibles para la mayoría de las cosas que queríamos para nuestra próxima CLI, pero algunos de ellos aún no eran compatibles con la última versión. ink versión. También tenía diffing similar a React para la salida de la terminal, lo que significaba que no sólo podíamos construir comandos interactivos, sino también tener una salida dinámica. Los contras no eran pocos, uno de ellos era el hecho de que estaba basado en React, y el equipo necesitaba estar familiarizado con él. Otro contra era que ink por sí solo no era adecuado para una gran CLI como la nuestra.

pastelpor otro lado, era un marco más adecuado, construido sobre inkque nos ofrecía las mismas ventajas, por lo que Dwane creó una PoC con él. pastel Pero , venía con sus propios contras, sobre todo el hecho de que no se había mantenido activamente en el último año, siendo la última versión de hace 10 meses.

Oclif

Construí el oclif PoC. La mayor ventaja fue que oclif cumplía la mayoría de nuestros requisitos, y funcionaba tal y como se anunciaba. Así que no tendríamos que construir una gran parte de la funcionalidad para los requisitos no orientados al usuario, como un sistema de plugins. También era más adecuado para la construcción de grandes CLIs. Las convenciones de estructura de código que utiliza facilitan el mantenimiento del código.

Sin embargo, también tiene un montón de contras. A pesar de que el sitio web anuncia tanto JavaScript como TypeScript como soportados, los documentos eran bastante TypeScript pesados, hasta el punto de que la mayoría de los casos de uso avanzados no estaban documentados en JavaScript.

El hecho de que elegí TypeScript para la construcción de la PoC también significaba que la importación de la Nexmo Node.js SDK sería problemático, así que tendríamos que invertir algo de tiempo en añadir soporte para TypeScript primero.

¿Y ahora qué?

Después de considerar cuidadosamente cómo nos afectaban todos esos pros y contras, decidimos seguir adelante y construir el próximo Nexmo CLI usando oclif.

Lo elegimos porque el soporte y la documentación eran excelentes, junto con la creciente comunidad de personas que lo utilizan. También se mantiene activamente. También estamos añadiendo soporte completo para TypeScript a nuestro SDK de Node.js, por lo que parecía un buen ajuste para mantener la misma pila a través de nuestro SDK y CLI.

Mientras trabajamos en la mejora de nuestro Nexmo CLI, puede seguir nuestro progreso en https://github.com/nexmo/nexmo-cli. Si tienes alguna sugerencia o problema, no dudes en plantearlo en GitHub o en nuestra comunidad slack.