linkどうもTypeScriptおにいさんです。2018年の記事です。i18nには多くの苦しみがありますが、ECMAScriptはASTの規格がしっかり決まっているおかげでパースしやすくてよいですね。今回ですが、またフワッとした話をします。コードをパッケージに切り出して公開するメリットはい。業務でコードを書いていて「あれ、もしかしてこの処理って汎用性あるんじゃない?」っておもうこと、あるんじゃないかとおもいます。いう感じで推奨しちゃう内容になります。実際にTypeScriptを例にとってnpmパッケージを公開する手順についてはまた後日紹介する予定です。今回は心構え編ですね。依存性を減らさざるを得なくなり、コードのクオリティがあがる普通にアプリケーションのコードを書いていると、大抵はどのロジックも暗黙の依存性を抱えこんでしまいます。単体テストのメリットの一つは、コードをテスタブルにする過程で依存性が明確になり、コードのクオリティが上がるというところにあるのではないかとおもいますが、パッケージ化はこれを更に推し進める形になります。パッケージ配布のエコシステムを知ることが出来るPyPIやnpmをはじめとして、各言語それぞれパッケージの公開と配布を行うエコシステムがあります。普通にコードを書いている場合はinstall用のコマンドだけを知っていれば事足りるため、別に知らなくても職業プログラマーとしてやっていくのに基本的に問題はありません。豊かな人生のためには幅広い知識があるに越したことはありません。あとJavaScriptを書いてていると稀によく発生するのですが、利用しているパッケージの依存が壊れている場合のトラブルシューティングは、この辺の知見がないと苦労するでしょう。どんな内容を学ぶのであれ、実践以上の近道はありません。再利用しやすくなる時々勘違いされていることがありますが、パッケージ管理ツールはかなり柔軟な形でのインストールが可能です。仮に公にできない類のライブラリであっても、作法に沿ったパッケージングをして管理しておくことで社内の各プロジェクトでの導入や更新がやりやすくなります。zipでの配布やソースコードのコピーでの運用をしなくて良くなるということですね。(可能であれば)OSSにすることで誰かの助けになるかもしれないこれを最初から目指してライブラリを作るのは単純な技術力に加えて様々な技能が必要になるため、あくまで付随するメリットとなりますが、他の誰かの需要に刺さって利用してくれる......あわよくばプルリクエストを送ってくれるかも......なんて可能性もなきにしもあらずです。可能なのであれば、積極的にOSSを公開することで社風をアッピールして採用がしやすくなるかもしれません。慣れないと大変これは各言語のエコシステムの出来にもよるとおもうのですが、実はできることがめちゃくちゃ多かったり、ドキュメントが不親切だったり......みたいな感じで最初の一歩がとにかく重たいです。筆者はPythonで最初の一歩を踏み出しましたが、当時のPythonはsetuptools問題などがありマジで辛かったことを思い出します。プログラミングは心の強さなのでがんばりましょう。セキュリティリスク業務ドメインのコードを入れるわけにいかないので依存性が減る......の項と微妙にかぶってしまうのですが、例えばセンシティブな内容がハードコードされていたコードを切り出して使ったが、一部見逃しがあったり、しょうもないコメントを消し忘れてたり、コードの中に脆弱性を匂わせる部分があり、そこから運用しているサービスを逆引きで探されたり......。可能性だけ上げればキリはないですが、しかしリスクがゼロではないということはちゃんと頭に入れておくべきでしょう。オーバーエンジニアリングになりがちさきほどから「依存性のないコード」なんて簡単に言ってますが、そういうコードを書くのは訓練が必要な特殊技能にあたると僕はおもっています。外部への再利用性なんかを一切考えずにべったりで書けばする書き上がるものなのに、パッケージ化を考慮したせいで余計な時間がかかってしまった、というのはありがちな問題です。前述したように、コードの純粋なクオリティは向上するのでどこかで手間はペイはするとおもうのですが、プロジェクトの進捗など、その時の状況に応じて対応する必要はあるかもしれません。まとめいかがだったでしょうか。今すぐにでもあのヘルパーやあのコンポーネントをパッケージ化したくなってきたんじゃあないでしょうか。やっちゃうといいとおもいます。「俺はフロント開発者じゃない、ただフロントが得意で書く機会...2018-12-11TypeScriptのモジュールをnpmで公開する方法はい。