CLIビルド・ライブラリの比較

Nexmoには CLIがあり ダッシュボード.コマンドラインからNexmoアカウントを管理し、Vonage製品を使用することができます。このツールは4年ほど前から使っており、Node.jsで書かれています。 で書かれています。.

先週 を書き直すのに時間をかけている理由について書きました。そしてNexmo CLIを書き直すために使っているプロセスについて少しお話しました。

今日は、さらに詳しく、私たちが分析したフレームワークとその基準を紹介します。また、概念実証を構築するために選んだフレームワークの長所と短所も紹介するつもりだ。

ベンチマーク基準

社内でCLIのレトロスペクティブを行い、一連の要件を特定した後、私たちはコマンド例のリストをまとめた。これらのコマンドは、コマンドライン・インタフェースを構築するために使用されるライブラリをベンチマークするための一連の基準を考え出すのに役立った。私たちの基準は、いくつかの質問に答えるものでした：

• 図書館はどの言語をサポートしていますか？

• 積極的に維持されているか？

• サブコマンドをサポートしているか？ nexmo app list

• 複数の出力フォーマットに対応していますか？

• プラグイン機構はありますか？

• コマンドは複数のエイリアスを持つことができますか？

• バイナリを生成できますか？

• コンフィグ管理とはどのようなものか？

• クロスプラットフォームですか？

• コマンドのオートコンプリートはありますか？

• インタラクティブなコマンドは可能か？

• グローバル・フラッグを定義できるか？

この切実な疑問のリストを武器に、私たちはできるだけ多くのCLIビルド・ライブラリを探し出し、私たちの条件リストに照らし合わせて、その機能をチェックしました。最終的には、チーム内で利用可能な言語スキルに基づいて、JavaScript、TypeScript、Go用の6つのライブラリに絞った： oclif, gluegun, ink, カポラル, クリそして コブラ.

機能比較

各フレームワークのホームページを見て、サポートされている機能をピックアップし、分析マトリックスを作成した。フレームワークがその機能を完全にサポートしていることを意味する❎、フレームワークがその機能をサポートしていないことを意味する❎、部分的なサポートしかないことを意味する✳️。以下は、私たちが特定した6つのフレームワークのマトリックスの様子です：

機能チェックリストを見ても、明確な勝者を特定することはできませんでした。そこで3つのフレームワークを選び、それぞれで概念実証を行うことにした。

POC

私たちが最初に選んだのは、コンセプトの実証を作ることだった。 oclif.プラグインをサポートし、プラグインをビルドするためのプラグインがある）。

番目に選んだのは caporalというのも、そのライブラリが現在のフレームワークとよく似ていたからだ、 commander.これなら、学習曲線も書き直す時間もかなり少なくて済んだだろう。

最後に、コンセプト実証のために選んだのは ink私たちがこれを選んだ理由は、十分な価値があり、巨大なエコシステムが背後にあるからだ。

フレームワークを特定した後、概念実証の範囲を考えました。私たちは、最終的なCLIを代表するものを作りたかった。 Hello Worldを作るのではなく、最終的なCLIを代表するようなものが欲しかった。同時に、この練習の終わりに概念実証を捨ててしまうのが嫌にならない程度に小さくなければならなかった。私たちは現在の nexmo setupと nexmo number:listコマンドを作ることにした。つまり、グローバル・フラグ、コンフィグ管理、サブ・コマンド、出力フォーマット、双方向性、さまざまな言語フレームワークをテストすることができるということだ。

次のCLI構築ライブラリを選ぶ

ローナ, ドウェインそして 私それぞれが3つのフレームワークから1つを選び、コンセプトの証明を作り始めました。それが終わると、それぞれのライブラリの長所と短所を紹介し、それが私たちの他の要件とどう関係しているかを説明しました。

カポラル

ローナは caporalPoC.最大の利点は、現在のCLIを commanderから caporalに移行できることだ。これはかなりの時間の節約になる。

短所は、ほとんどが現在の commanderこのプロジェクトは、私たちが望むほど積極的にメンテナンスされていない。プロジェクトをフォークし、その周りのコミュニティを維持しなければならないだろう。また、プラグインのような私たちの要求のいくつかは、ゼロから構築する必要がある。

インク

ドウェインは inkPoCを構築した。最大の長所は、Reactをフレームワークとして使っていることで、巨大なコミュニティとエコシステムがある。Reactには、私たちが次のCLIに望んでいるほとんどのことに対応するプラグインがたくさん用意されていたが、そのうちのいくつかはまだ最新バージョンと互換性がなかった。 inkバージョンとまだ互換性がないものもあった。また、ターミナル出力にはReactのような差分機能があり、インタラクティブなコマンドをビルドできるだけでなく、動的な出力も可能だった。短所は少なくなかったが、そのひとつはReactベースであることで、チームはReactに精通する必要があった。もうひとつの短所は ink私たちのような大規模なCLIには向いていませんでした。

pastelの上に構築された、より適したフレームワークだった。 inkそのため、ドウェインはそれを使ってPoCを作った。 pastelとはいえ、それなりの欠点もあった。そのほとんどは、この1年間積極的にメンテナンスされていなかったことで、最後のリリースは10ヶ月前だった。

オクリフ

私は oclifPoC.最大の長所は oclifは、私たちの要求のほとんどを満たしていて、宣伝通りに機能したことです。そのため、プラグイン・システムのような、ユーザーを対象としない要件のために多くの機能を構築する必要がなかった。また、大規模なCLIの構築にも適していた。コード構造の規約を使用しているため、コードのメンテナンスも簡単です。

しかし、短所もたくさんあった。ウェブサイトではJavaScriptとTypeScriptの両方がサポートされていると宣伝しているにもかかわらず、ドキュメントはかなりTypeScript偏重で、高度なユースケースのほとんどがJavaScriptで文書化されていないほどだった。

PoCを構築するためにTypeScriptを選んだということは、TypeScriptをインポートするということでもある。 Nexmo Node.js SDKをそのままインポートするのは問題があるので、まずはTypeScriptのサポートを追加するために時間を割く必要がある。

次はどうする？

これらの長所と短所が我々にどのような影響を与えるかを慎重に検討した結果、我々は次のNexmo CLIを構築することにした。 oclif.

私たちは、サポートとドキュメントが充実していたことと、それを使っている人たちのコミュニティが広がっていたことから、このシステムを選びました。また、メンテナンスも積極的に行われています。また、私たちはNode.js SDKにTypeScriptのフルサポートを追加しているので、SDKとCLIで同じスタックを維持するのが適していると思いました。

Nexmo CLIの改良に取り組んでいますが、その進捗状況は以下でご覧いただけます。 https://github.com/nexmo/nexmo-cli.何か提案や問題がありましたら、GitHub または コミュニティ・スラック.