TypeScriptの勉強のために小さなnpmパッケージを作成・公開しました。本記事は、パッケージを作成・公開するときに学んだこと・つまづいたことをまとめた内容になります。
本記事で言いたいことは、TypeScript の勉強法としてnpmパッケージ作成は適しており、公開するだけであればその敷居は思ったより低くないということです。
作ったもの
commitlintという、コミットメッセージがコミット規約に従っているのかどうかをチェックするnpmツールがあります。
ESlintのように、プラグイン・ルールを組み合わせて拡張することで、プロジェクトに合ったコミット規約をカスタマイズできます。
今回は、コミットメッセージがIssue 駆動開発のコミット命名規則に則っているかどうかをチェックする、とても小さなプラグインを作りました。コミットメッセージ本文に#issue番号があるかどうかをチェックするだけのルールで、ほぼ自分用に作ったものではありますが、もしよければ使ってくださると幸いです。
作った動機
自分は普段Goでバックエンド開発をしているのですが、直近でTypeScriptの知識が必要になりました。
そこで、プログラミング TypeScript等を読んで基本的な読み書きができるようになったのですが、何か1つ作ってみるかとなり、React×TypeScriptでのアプリ開発を考えました。しかし、筆者はReactに精通しているわけでもないため、ハマった時に何が原因なのかが混乱してしまい、学習効果が薄くなるだろうと考えました。
- TypeScript 単体の勉強としてコードを書きたかった
- node_module の勉強もしたかった
上記の動機から、簡単なnpmパッケージを作ることにしました。
どのようにして作っていったか
以下の順番で進めていきました。
- npmパッケージの作成・公開フローを知る
- commitlintのプラグインの開発ルールを知る
- npmパッケージ公開用のTypeScriptのビルド設定を知る
- 他のcommitlintプラグインのコードを真似ながら、開発していく
また、開発を進める際は以下の資料を参考にしました。
npm パッケージの作り方
TypeScript のビルド設定周り
の[TypeScriptのビルドと実行]の章。
あとは、@commitlintの型を使うため@commitlint/typesのソースコードを読んだり、npmで他のcommitlintのプラグインのソースコードを探して読んだりしました。
学べたこと
実際にTypeScriptで書いたコードは、ちょっとしたスクリプト程度の量でした。そのため、「TypeScript完全に理解した」というより、JavaScript・TypeScriptのエコシステムについて学んだことが多かったです。
TypeScript のビルド周りの設定
TypeScriptはバイナリではなく、JavaScriptのソースコードをビルドします。そのため、どのプラットフォームで動くJavaScriptを生成するか等を決める必要があり、それらの設定はtsconfig.jsonで細かく指定ができます。
業務では、他の開発者の方が設定してくれているので、今回位置から設定することでTypeScriptのビルド設定を知る良い機会になりました。
また、「export ？ module.exports？どっちがどっちで、何がちがうのか？」といったCommonJsとNode.jsの記述の違いについて理解しておかないといけないため、開発前のタイミングで他の方が書かれたJavaScript の変遷について説明した記事などで知識を整理できたのも良かったです。
TypeScript の型定義
今回作成したcommitlintプラグインのソースコードでは、@commitlintの型を使用しています。その際に@commitlintのソースコードを読んだのですが、ジェネリクスの使い方などは非常に参考になりました。
保守性・拡張性の高いOSSのコードを読むことは、TypeScript初心者にとってとても良い勉強方法だったのではないかと思います。
npm パッケージの公開の仕方
npmパッケージはインストールして使ったことは何回もありますが、公開したことはありませんでした。開発前は設定が色々必要なのかな？と思っていたのですが、npmパッケージ開発の方法について解説している記事が多く、そもそもnpmパッケージの公開が簡単だったこともあるため敷居は低かったです。
つまづいたポイント
開発に必要なツールの設定
**eslintやprettier、jestの設定につまづきました。**TypeScriptの開発をするために、どのパッケージをインストールしたり、設定を追加すればよいのかを把握するのに時間をかけてしまいました。よくわからないまま他のプロジェクトを真似て突っ込むのではなく、ドキュメントを確認しながら1つづつ入れていけば良かったです。
個人の感想ですが、Goと比較すると、こちらは諸々の設定が面倒だなと感じました（単に自分に知識が足りないことや慣れの問題もあります）。Goは言語に標準でフォーマッタやテストツールが付属しており、Go用のVSCode拡張を入れれば動くので使いやすいです。
また、設定ファイルは.js・yml・jsonなんでもござれという点には面食らいました。
動作確認方法
yarnやnpmには、linkというローカルの開発中のnpmパッケージに対してシンボリックリンクを貼り、手元で動作確認できる仕組みがあります。
**誠に恥ずかしながら、開発中の自分はこの仕組みを知りませんでした。
**「テストに通っているからこれでええやろ!」と一通りユニットテストを行いつつ、パッケージとして組み込んだ際の動作はスクリプトをそのままcommitlintに組み込んだりして確認していました。
そのため、実際の動作確認はnpmに公開してから行っていました。今振り返るととんでもないことです。普通に考えると何かしら動作確認ができる仕組みはあるはずなのですが、自分は気づきませんでした。npmほどのプラットフォームであれば、必ず開発ツールは充実しているはずなので、焦らずうまく検索Wordを変えて根気よく調べられれば良かったです。
おわりに
npmパッケージをTypeScriptで書くことによって、コードの書き方だけでなく巨大なJavaScriptのエコシステムについてもある程度学べる機会となりました。
ある程度入門的な内容（リテラルの書き方など）を勉強した後に、何かサラッと書いてみる分には、npmパッケージ開発はうってつけだと思います。