社内でnpmパッケージを開発したときの振り返り

この記事はポート株式会社 サービス開発部 Advent Calendar 2024 の24日目です🎄🤶

はじめに

ポート株式会社でフロントエンドエンジニアをしているminamiです。
普段はキャリアパークや就活BOXなどのサービス開発を担当しています。

この記事について

1年ほど前に、社内サービス用のnpmパッケージを作成する機会がありました。
作成したパッケージは現在社内で運用されていますが、いくつかの反省点があります。
本記事では、作成当時を振り返りながら、今の自分が考える「こうすれば良かったな」をまとめました。

※本記事ではnpmパッケージの作成方法はまとめていません。

作成したパッケージについて

作成したパッケージの要件と概要は以下の通りです。

- 会員登録フォームの新規UIコンポーネント

## 作成要件
- 社内サービスのみで運用する
- 既存の親サービスからコンポーネントを切り出し、npmパッケージ化する

## 導入背景
- 元々運用していた会員登録フォームパッケージは、機能以外のデザインや内部構造が異なっていた
- そこで、同様の機能やコンポーネントを一元管理できるようにし、複数ある他サービスで利用できるようにしたい

## パッケージの技術スタック
- 当時の親サービスと共通
  - ビルドツール：webpack v5.90.3
  - 言語：TypeScript v4.9.5
  - フレームワーク：React v17.0.2

長期的な運用を考えたビルドツールの選定

当初、親サービスとの統一性と、私自身の経験を考慮し、webpackを採用しました。
しかし導入後以下の課題が顕在化しました。

• 設定ファイルの複雑さ
  • 親サービスの設定をそのままパッケージに流用したため、新規開発者が理解しづらい状態になっていた
• 本番環境下の圧縮ファイルの肥大化
  • 本番環境においてパッケージの占めるファイルサイズが大きかった
  • その結果、パッケージを読み込んでいるページにおいて、フォーム描画速度が遅く、ユーザ体験の低下原因となっていた

上記の観点から現在はViteが導入されています。

これにより上記の問題を解決したほか、HMRが高速であるため開発効率の向上も実感しています。
プロジェクトの規模や特性に合わせた最適なビルドツールを選択することが重要だと理解しました。

依存パッケージは最新版を利用する

当たり前なのですが、セキュリティなどの観点から常に最新の状態に保つことが重要です。
webpackと同様に、親サービスで利用しているバージョンをそのまま利用する形になっていました。
特定のバージョン下でしか動かないような稀有な実装はなかったので、パッケージに切り出す際に最新版にアップデートをすべきだったなと反省しています。

今後の対応として、dependabotやrenovateを導入することでバージョン管理を進めていきたいと考えています。

ESMの考慮をすべきだった

当時の自分はCJSとESMの違いはおろか、存在すらよくわかっていなかったため、当時使っていた環境の影響もあり、自動的にCJSのパッケージが出来上がりました。
現在の運用においては問題ありませんが、今後はJavaScriptの標準仕様であるESMが主流になるため、CJSとESMのどちらでも読み込めるように対応したいと考えています。

まとめ

今回の記事のまとめです。

• 長期的な運用を見据えてビルドツールを選択しよう
• 依存パッケージは常に最新のものを導入しよう
• CJSとESMのどちらでもimportできるように対応しよう
• フロントエンドの情報に敏感になろう

おわりに

今回の経験は、私にとって大きな学びとなりました。
私は既存仕様に囚われがちなことが多いので、日常的に新しい技術に目を向け、最適なものを選ぶようにしたいと考えています。
今後も、変化を恐れずに新しい技術に挑戦し、より良い開発をしていこうと思います。

クリスマスに間に合って良かったです🎄🔔（アドカレ担当日には間に合ってない）