Vergleich von CLI-Bibliotheken

Nexmo hat eine CLIdie wir als Alternative zum Dashboard. Es ermöglicht Ihnen, Ihren Nexmo Account zu verwalten und Vonage Produkte von der Kommandozeile aus zu nutzen. Wir haben dieses Tool seit etwa 4 Jahren, und es ist geschrieben in Node.js.

Letzte Woche habe ich darüber geschrieben, warum wir uns die Zeit nehmen, es neu zu schreibenund ich habe ein wenig über den Prozess berichtet, mit dem wir die Nexmo-CLI neu schreiben.

Heute werde ich mehr ins Detail gehen und die Frameworks vorstellen, die wir analysiert haben, sowie die Kriterien, die wir dafür verwendet haben. Ich werde Ihnen auch einige Vor- und Nachteile der Frameworks aufzeigen, die wir für die Erstellung unserer Proofs of Concept ausgewählt haben.

Benchmark-Kriterien

Nachdem wir unsere interne CLI-Retrospektive durchlaufen und eine Reihe von Anforderungen ermittelt hatten, stellten wir eine Liste von Beispielbefehlen zusammen. Diese Befehle halfen uns, eine Reihe von Kriterien für den Vergleich von Bibliotheken zur Erstellung von Befehlszeilenschnittstellen aufzustellen. Unsere Kriterien sollten ein paar Fragen beantworten:

• Welche Sprache unterstützt die Bibliothek?

• Wird sie aktiv gepflegt?

• Unterstützt es Unterbefehle, z. B. nexmo app list

• Bietet es integrierte Unterstützung für mehrere Ausgabeformate?

• Verfügt es über einen Plugin-Mechanismus?

• Können Befehle mehrere Aliasnamen haben?

• Kann es Binärdateien erzeugen?

• Wie sieht das Konfigurationsmanagement aus?

• Ist sie plattformübergreifend?

• Verfügt es über eine automatische Befehlsvervollständigung?

• Kann es interaktive Befehle haben?

• Können wir globale Flaggen definieren?

Mit dieser Liste von brennenden Fragen bewaffnet, machten wir uns auf die Suche nach möglichst vielen CLI-Bibliotheken, die die meisten dieser Fragen erfüllten und ihre Funktionen anhand unserer Liste von Qualifikationskriterien abhaken konnten. Am Ende haben wir uns auf sechs Bibliotheken für JavaScript, TypeScript und Go beschränkt, basierend auf den vorhandenen Sprachkenntnissen im Team: oclif ..., gluegun, ink, caporal, cli und cobra.

Vergleich der Merkmale

Wir sind die Homepage jedes Frameworks durchgegangen und haben die von ihnen unterstützten Funktionen herausgesucht und eine Analysematrix erstellt. Wir verwendeten ❎, um zu sagen, dass das Framework diese Funktion vollständig unterstützt, ❎, um zu sagen, dass das Framework diese Funktion nicht unterstützt, und ✳️, um zu sagen, dass es nur eine teilweise Unterstützung gibt. So sah unsere Matrix für die 6 von uns identifizierten Frameworks aus:

Mit Blick auf die Feature-Checkliste konnten wir keinen klaren Gewinner ermitteln, zumal es noch einige Unbekannte gab. Also beschlossen wir, 3 Frameworks auszuwählen und mit jedem von ihnen einen Proof of Concept zu erstellen.

PoCs

Unsere erste Wahl zur Erstellung eines Proof of Concept war oclif. Der Hauptgrund, warum wir uns dafür entschieden, war, dass es die meisten unserer Anforderungen zu erfüllen schien, einige sogar doppelt (es hatte Plugin-Unterstützung und ein Plugin, mit dem man Plugins erstellen konnte).

Die zweite Wahl war caporal weil die Bibliothek unserem derzeitigen Framework recht ähnlich zu sein schien, commander. Dies würde bedeuten, dass die Lernkurve und die Zeit, sie neu zu schreiben, wesentlich geringer gewesen wären.

Unsere letzte Wahl für den Proof of Concepts war schließlich inkWir haben uns für dieses Projekt entschieden, weil es genügend Kriterien erfüllt, um es lohnenswert zu machen, und weil es von einem großen Ökosystem unterstützt wird.

Nachdem wir die Frameworks identifiziert hatten, legten wir einen Rahmen für den Proof of Concepts fest. Wir wollten etwas, das repräsentativ für die endgültige CLI ist, anstatt ein Hello World Beispiel. Gleichzeitig sollte es so klein sein, dass wir kein schlechtes Gewissen haben mussten, wenn wir den Konzeptnachweis am Ende dieser Übung wegwerfen. Wir entschieden uns für den Bau der aktuellen nexmo setup und nexmo number:list Befehle. Das bedeutete, dass wir globale Flags, Konfigurationsmanagement, Unterbefehle, Ausgabeformate, Interaktivität und verschiedene Sprachframeworks testen konnten.

Die Auswahl unserer nächsten CLI-Gebäudebibliothek

Lorna, Dwane und ich nahmen sich jeweils eines der drei Frameworks vor und begannen mit der Erstellung unserer Proofs of Concepts. Als wir fertig waren, haben wir einige der Vor- und Nachteile der Arbeit mit den einzelnen Bibliotheken vorgestellt und gezeigt, wie sie sich auf einige unserer anderen Anforderungen beziehen.

Caporal

Lorna hat das caporal PoC. Der größte Vorteil war, dass es möglich war, unsere aktuelle CLI von commander zu caporal zu migrieren, ohne dass eine vollständige Neuprogrammierung erforderlich ist. Das würde uns eine Menge Zeit sparen.

Die Nachteile waren größtenteils ähnlich wie unsere derzeitigen commander Einschränkungen, und das Projekt wird nicht so aktiv gepflegt, wie wir es uns gewünscht hätten. Wir müssten das Projekt wahrscheinlich abspalten und eine Community darum herum aufbauen, was einen Teil des Geschwindigkeitsgewinns zunichte machen würde, wenn wir es nicht neu schreiben müssten. Es würde auch bedeuten, dass einige unserer Anforderungen, wie z.B. Plugins, von Grund auf neu entwickelt werden müssten.

Tinte

Dwane baute das ink PoC. Der größte Vorteil war die Verwendung von React als Framework, das eine riesige Community und ein Ökosystem mit sich bringt. Es gab eine Menge Plugins für die meisten Dinge, die wir für unser nächstes CLI wollten, aber einige von ihnen waren noch nicht mit der neuesten Version kompatibel. ink Version. Es hatte auch ein React-ähnliches Diffing für die Terminalausgabe, was bedeutete, dass wir nicht nur interaktive Befehle erstellen konnten, sondern auch dynamische Ausgaben hatten. Die Nachteile waren nicht gering, einer davon war die Tatsache, dass es auf React basierte und das Team damit vertraut sein musste. Ein weiterer Nachteil war, dass ink allein nicht für ein großes CLI wie unseres geeignet war.

pastelwar dagegen ein besser geeignetes Framework, das auf der Grundlage von inkaufsetzte, das uns die gleichen Vorteile bot, weshalb Dwane einen PoC mit diesem Framework erstellte. pastel Das Framework hatte aber auch seine eigenen Nachteile, vor allem die Tatsache, dass es im letzten Jahr nicht aktiv gepflegt wurde, die letzte Version ist 10 Monate her.

Oclif

Ich habe den oclif PoC. Der größte Vorteil war, dass oclif die meisten unserer Anforderungen erfüllte, und sie funktionierten wie angekündigt. So mussten wir einen Großteil der Funktionalität für die nicht benutzerorientierten Anforderungen, wie ein Plugin-System, nicht selbst entwickeln. Es war auch besser geeignet für die Erstellung umfangreicher CLIs. Die Konventionen für die Codestruktur, die es verwendet, machen es einfacher, den Code zu pflegen.

Es gab aber auch eine Reihe von Nachteilen. Obwohl die Website sowohl JavaScript als auch TypeScript als unterstützt anpreist, waren die Dokumente ziemlich TypeScript-lastig, bis zu dem Punkt, dass die meisten der fortgeschrittenen Anwendungsfälle nicht in JavaScript dokumentiert waren.

Die Tatsache, dass ich TypeScript für die Erstellung des PoCs gewählt habe, bedeutete auch, dass der Import des Nexmo Node.js SDK in das PoC zu importieren, problematisch sein würde, so dass wir zuerst etwas Zeit in die TypeScript-Unterstützung investieren müssten.

Was kommt als Nächstes?

Nach sorgfältiger Abwägung all dieser Vor- und Nachteile haben wir uns entschieden, die nächste Nexmo CLI mit oclif.

Wir haben uns dafür entschieden, weil der Support und die Dokumentation dafür großartig sind und die Gemeinschaft der Anwender wächst. Es wird auch aktiv gepflegt. Außerdem fügen wir unserem Node.js-SDK volle Unterstützung für TypeScript hinzu, sodass es uns sinnvoll erschien, den gleichen Stack in unserem SDK und CLI zu verwenden.

Während wir an der Verbesserung unserer Nexmo CLI arbeiten, können Sie unsere Fortschritte unter https://github.com/nexmo/nexmo-cli. Wenn Sie Vorschläge oder Probleme haben, können Sie diese gerne auf GitHub oder in unserem Community Slack.