https://ozaki25.hatenadiary.jp/entry/2023/12/11/214450

社内ツールから生まれたOSS "ts-remove-unused" によるフロントエンド開発の効率化と品質の向上

https://github.com/line/ts-remove-unused
export付いてるのに利用されてないコードを削除してくれる
- exportがなければlintでき付けるけどexportあると気づきづらい
なぜ作ったか
- コンポーネントライブラリを置き換える時にデッドコードが大量に発生した
- 依存関係をたどる必要があり簡単に削除できない
構文の解析
- TypeScript Compiler APIで操作できる
- TypeScript Compiler APIをラップしたts-morphというライブラリもある
  - https://github.com/dsherret/ts-morph
振り返って
- 全部のケースをカバーできなくても手動でやるより効率化できた

合併に際して新しいポリシーの同意画面のSDKを作った
- Modal版/FullScreen版
- いろんなサイズのいろんなデバイスに対応させる必要があった
- iOS/Android/Web
苦労した点
- 影響度
  - ヤフーサービス利用者5400万人
  - サービスの利用体験に影響する
  - 広告に影響が内容シビアな速度
  - 法的/ビジネス的影響度
- 対象範囲
  - 様々なOS/ブラウザ/通信環境
  - 数千万台のデバイスで安定動作が必要
  - 1つのミスや考慮不足が致命的な問題に
  - シェア0.1%でも無視できない
- 保守性
  - 開発後は案件先の担当者だけで運用できるように
    - エラーコードを細かく整備
    - コードを見ただけでどこでどんなエラーが起きたか分かるように

LINE公式アカウントの管理画面
- WebとiOS/Android向け
Vueファイル2600超え
機能が多岐だが利用頻度はまちまち
- 特定ユーザ向けの画面がたくさんある
Bootstrap4をカスタマイズした独自ライブラリ
- 問題なく使えてるがCSSへのパッチが増えていき変更困難に
Tailwindへの移行を徐々に
- BootstrapのckassがTailwindと重複するのでprefixつけたり
TailwindはユーティリティなのででCSSフレームワークを作ろうとするとUIコンポーネントを作る必要がある
- 今後他の画面でも使われるかもしれないのでVue依存はダメ
- WebComponentsで作ろうか

フレームワークに依存しないUIコンポーネントを提供できる
ShadowDOMでスコープ分離できる
いろいろ問題が
- 開発パラダイムの違い
- 既存FWとの親和性
- SSR対応
WebComponentsの開発
- litを使ってる
- ClassベースなのがFE開発とコンテキストスイッチを切り替える必要あり
- litのmixinがTS対応が難しい
Zag
- https://zagjs.com/
- UIコンポーネント実装のためのライブラリ
- ArkやPandaCSSはZagベース
- FWに依存しない実装でReact/Vue/Solidに対応
- litにも対応可能
- Classベースではない
- ステートマシンで状態管理を抽象化できる
- WebComponentsからの脱却も見据えることができる
custom-element-manifest
- WebComponentsをReactなどで使えるようにラップしたい
- jsonで宣言してコンポーネントを自動生成する
SSR対応
- エコシステムとしてはまだ
- 今回の事例ではSSR必要なかった
- Declarative ShadowDOM
  - SSRでShadowDOMを使える技術
  - まだ全ブラウザで使えるわけではないので今後に期待