この記事は、静的解析とビルドサイズ面で興味深いテーマでした。記事として自分の考えを書きます。

https://zenn.dev/yumemi_inc/articles/ts-enum-like-const

注意。あくまでビルドパフォーマンス視点での最適化です。強い意図があって、自分のドメインモデリングの方法論ではこれが最適なんだ、というなら元コードの方法論を止めるつもりはありません。

元記事のコードを minify するとどうなるか

元コードを参考に、それにアクセスするサンプルコードを書いてみます。

const sortingOptions={priceDesc:{id:"priceDesc",sort:"price",order:"desc",label:"価格が高い順",},priceAsc:{id:"priceAsc",sort:"price",order:"asc",label:"価格が安い順",},ratingDesc:{id:"ratingDesc",sort:"rating",order:"desc",label:"平均評価が高い順",},ratingAsc:{id:"ratingAsc",sort:"rating",order:"asc",label:"平均評価が低い順",},}const labels=[  sortingOptions.priceDesc.label,  sortingOptions.priceAsc.label,  sortingOptions.ratingDesc.label,  sortingOptions.ratingAsc.label,];console.log(labels);

minify 時は型は残らないので、terser のプレイグラウンドで試しやすくするために落としてあります。

自分で試したい人はhttps://try.terser.org/

結果

const e=[{id:"priceDesc",sort:"price",order:"desc",label:"価格が高い順"}.label,{id:"priceAsc",sort:"price",order:"asc",label:"価格が安い順"}.label,{id:"ratingDesc",sort:"rating",order:"desc",label:"平均評価が高い順"}.label,{id:"ratingAsc",sort:"rating",order:"asc",label:"平均評価が低い順"}.label];console.log(e);

オブジェクトがまるっと残り、そのうち一部にアクセスすることで、ほとんどランタイム上でデッドコードになります。

これを消す方法があります。

最適化可能なコード

あくまで自分ならこう書く、という例です。

constenum SortingOptions$Labels{  priceDesc="価格が高い順",  priceAsc="価格が安い順",  ratingDesc="平均評価が高い順",  ratingAsc="平均評価が低い順",};constenum SortingOptions$Order{  desc="desc",  asc="asc",}constenum SortingOptions$SortType{  price="price",  rating="rating",}const labels=[  SortingOptions$Labels.priceDesc,  SortingOptions$Labels.priceAsc,  SortingOptions$Labels.ratingDesc,  SortingOptions$Labels.ratingAsc];console.log(labels);

$ を名前空間的なセパレータとして使ってますが、そこは好みの問題です。enum を使いたくないなら、export const SortingOptions$Labels$priceDesc = ... と更に区切ってすべて展開します。

tsc + terser で次のように変換されます。

console.log(["価格が高い順","価格が安い順","平均評価が高い順","平均評価が低い順"]);

オブジェクト定義は綺麗サッパリ消え、定数だけがインライン化されました。

...自分に有利なベンチマークをしたことは認めます。ただ伝えたいのは、元コードは静的解析でビルドサイズを削る余地が残ってないのに対し、修正後のコードは未使用コード削ることができる、という点です。

これはプロジェクトが巨大な設定値を持つとき、問題として現れる可能性があります。例えばサーバーのバリデーション用の巨大な jsonschema を自前のコンバータでネストオブジェクトに変換してクライアントで使う、というようなシナリオで、実際にパフォーマンスが悪化したのを見たことがあります。

名前空間的再exportのアンチパターン

正直、上記のケースはほとんどのケースで些末な問題です。自分のモデリングではこうなんだと言われたら、特に止めません。ビルド面で不利なのは伝えますが。

問題なのは、export default {...} のパターンでこれを行ったときです。これについては元記事で踏んでいる問題ではないですが、上記の問題の解説を兼ねて、連続的な問題として取り上げます。

次のようなコードをよく見かけます。

import afrom"./a";import bfrom"./b";exportdefault{a, b}

デフォルトの名前空間としての一時オブジェクトを作成し、そのメンバとして値や関数を登録します。これは一見、同類のオブジェクトを再梱包して整理したコードに見えます

ですが、静的解析視点では、import 側が default オブジェクトの getter で何にアクセスするか、import 時に静的解決で解決できない、という問題が発生します。

import nsfrom"./api";console.log(Object.keys(ns));

自分はこれを「名前空間的再 export のアンチパターン」と勝手に呼んでいます。Terser などの minifier では、残念ながらオブジェクトにアクセスするレベルでの使用/未使用は最適化の範囲外で、理由としては getter による迂回の可能性が言語仕様レベルで否定できないからです。

exportdefault{x:1,gety(){returnthis.x+1;}}

...これは些細な問題でしょうか？

自分は経験的に、これこそが大問題を引き起こすと考えています。export defalut {..} はなんでも一時オブジェクトに詰め直すことで tree shake の対象外にします。結果すべてをビルドチャンクに含めてしまいます。

フロントのパフォーマンスだけならまだマシです。Next.js のようなクライアント/サーバーでモジュールを共有する環境では、次のような簡単なコードでセキュリティインシデントを発生させます。

// packages/shared/constants.tsconstCLIENT_ID=1;constSERVER_SECRET_TOKEN="secret-id!!!";// import 先で常にすべての値が露出する。exportdefault{CLIENT_ID,SERVER_SECRET_TOKEN}

自分は個人的に、APIスタイルに個人的の主観的な好みを持ち込むべきではなく、定量化された指標、例えばビルドサイズやカバレッジ、実行時コストで測るべきだと考えています。

自分の結論

昔、terser を複数回掛けたらコードが縮む例を調査したことがあります。その時の結果を引用しておきます。

https://zenn.dev/mizchi/articles/terser-many-times

ここから導かれるベストプラクティスは、とりあえず terser を複数回掛ける… ではなく、「定数宣言はオブジェクトメンバでやらない」ということです。terser にとっては無用な苦労です。

Programmer in the Loop