高速JSバンドラをつくる
Why?
最近，JSバンドラがJS以外の言語で書かれ始めている
esbuild，swc，etc……
これらの技術の根本的な問題意識として，「V8の起動時のJSパフォーマンスがあまりよろしくない」というのがあると思っているtosuke.icon
TurboFanが最適化を終えるのには時間がかかり，その間動いているIgnitionはバイトコードインタプリタなので(最適化されているとはいえ)あまり速くはない
Baseline JITであるSparkplugが出てきたのでここらへんはひっくり返るかもしれない
tosuke.iconはその言語のエコシステムはその言語で書かれていたほうがいいと思っている
プラグイン機構が簡単に用意できないかもしれない
GoやRustでこれをやるのは，JavaScriptより遥かに難しい
問題が起きたときに，簡単に解決できないかもしれない
JavaScriptだったらコードを読みに行ってすぐに解決できる/パッチを当てられる
既存のエコシステムを活用できる
ライブラリが提供するBabelプラグインを使いたい場合とかある
余談
この点Parcelはうまくやってる
babel-preset-envやbabel-preset-typescriptは重いからswcにやらせよう！というアイデア
ある程度ユースケースが固まったところを決め打ちして高速化するの，頭いい
How
基本方針
並列化したら速くなるんじゃね?
並列化できない箇所はLiftoffのパワーに期待してWASMで書く(やる気があったら)
これが可能になるように，JavaScript-WASM間のデータの受け渡しが高速になるようなデータの持ち方をする
巨大なデータをスレッド間で受け渡さない
設計
「Host」と「Worker」を使う
Host x1，Workerたくさん
Host
主にモジュールの依存関係を管理する
新しいモジュールが発見されたら，それを空いているWorkerに伝えて割り振る
Tree Shaking
Workerから集めた識別子の情報を舐めて，使われていないかつ副作用がなければWorkerに「この識別子は消してよい」と伝える
Naming
Terserの持つ最適化機構のうち，名前付けの部分をHostでやりたい
ここだけ大域的な情報に依存していて，並列化できない
ある程度妥協して，トップレベルの名前付けだけやって，ローカルはTerserにいい感じにしてもらうとか?
どうやって名前空間分けようか
全てのモジュールを探索したら，トポロジカルソートしてWorkerに出力させる
Prefix sumを使うのも検討したい
Worker
モジュールを保持して操作する
ASTは巨大なので，動かさずにWorkerに保持して，情報はモジュールを持ってるWorkerに聞きに行くというスタイルにする
どのモジュールを誰が持っているのかという情報が欲しくなるはずで，Mapをv8.serializeしたものをSharedArrayBufferに入れて配るとかするとよさそうな気がする
Hostにモジュールを割り振られたら
1. パース
2. Babelプラグインを適用して変換
3. 依存関係の収集
importを調べる
最低限，モジュールの存在と依存は調べる必要がある
Tree Shakingやるならこれらも調べないといけない
モジュール全体への依存があるかimport * as hoge from ...
副作用があるかもしれないモジュールだと，使われてなくても全体を含める必要がある
hogeをオブジェクトとして扱う必要があるかどうかも調べる
moduleをオブジェクトとして作る必要があるかに関わってくる
これが必要だと，確定でTree Shaking不可
importされた識別子と，それが使われているか
識別子の登場回数もあるとうれしい?(naming)
モジュール全体への非同期依存があるか(import())
Tree Shakingのために，内部の依存関係を収集
収集した情報をHostに伝えて待機
4. バンドラ特有の変換
モジュールを正しい順番でconcatしたときに，名前空間の衝突なく動作するような変換をする
バンドラが全てのモジュールの情報を知らないとできないことも多いので，それが終わったらゴリゴリやる
トップレベルの識別子に$$abcedfみたいなsuffixを付けて，それへの内部依存を全部変更
Tree Shaking
Hostに削除しろと言われた関数/変数の定義を，内部依存がないなら削除
importを除去
import * as hoge from (idがabcdefなモジュール)は
hoge.piyoの形ならpiyo$$abcdefに，hoge.defaultの形なら__default$abcdefに
const { piyo } = hogeとかでもやる
それ以外ならコード中のhogeを__module$abcdefみたいなのに
import hoge from ...はコード中のhogeを__default$abcdefに
import { hoge } from ...はhogeをhoge$$abcdefに
import(...)はちょっと厄介
Dynamic Importを考えない場合，Promise.resolve(__module$abcdef)にすればいい
Dynamic Importを実装する場合
そもそもこのフェーズだと全てのモジュールの解決が終わっていないので，モジュールの解決と分割が終わってから戻ってきて以下のことをやる
Module Concatenationを考えない場合
そのままimport()の中身をいい感じにして変換してあげればいい
考える場合
import().then(絞り込む関数)みたいにする?
exportの処理
ルートのモジュールだったら
Named Exportはexport { hoge$$abcdef as hoge }みたいなのを末尾に付ける
Default Exportはそのまま
ルートではない場合
識別子の末尾にモジュールIDを付与しているのでNamed Exportは考えなくていい
Default Exportが依存されている場合にexport default hogeをconst __default$abcdef = hogeに
モジュールをオブジェクトとして扱う必要がある場合，const __module$abcdef = { ... }みたいなコードを生成
実際はprototypeをnullにしないといけないので，Object.freeze(Object.assign(Object.create(null), { ... }))になる
5. 出力
ArrayBufferに書き出して，バイト数を知っておく
ファイルに書き込む
#idea #怪文書