AI時代を迎えて、どう勉強すべきだろうか？
どんな専門性が求められるのか、どのような能力が今の時代に最も価値があるのか、見当がつきませんでした。
開発者を雇う会社も、開発者自身も、明確な基準がわからないという点では同じだと思いますが、
それでも、じっとしていたら確実に損をするという気はしていました。
とりあえず何か作ってみようと思い、
学習用として最初は単純にChrome Remote DevToolsを作るところから始めました。
作っているうちに、React Nativeもリモートデバッガーで対応できるようにしてみよう
-> Metroを知らないので難しすぎる。
-> Metroをクローンコーディングしながら勉強してみよう
-> React NativeでMetroより良いバンドラーを作れないだろうか？
-> Rolldown、swc、bunを通していろいろ触りながら、Metroバンドラーより良いバンドラーを作ろうと努力。
その中ではbun、Rolldownに可能性がありましたが、あれこれメイン側をカスタムしたりフォークを切ったりすることに限界を感じました。
とはいえ、Metroバンドラーと完全互換のWebバンドラーもありません。flow、Hermesエンジンが許容するJavaScript構文、さらに一般的なWebとは違って重要な呼び出し順序など……
ああ……どうせ勉強なんだから、いっそバンドラーも作ってReact NativeのMetroを置き換えてみよう。
バンドラーを作りながら感じたこと。
じゃあ、Webもサポートすればいいんじゃない？
Rolldownが諦めたES5も入れよう
RNを動かす必要があるからFlowパーサーもサポートしよう
wasmもサポートしよう
速度でも bun、Rolldownに勝ってみよう
独自HMRも入れよう
ツリーシェイキングももう少し攻めてみよう
minifyも他のバンドラーより先を行こう
既存のバンドラーをベンチマークで、とりあえず自分が認識している機能については全部上回ろう、という考えで開発しました。
もちろん、多くの部分では負けているだろうとも思っています。
他のバンドラーと比べれば、安定性や機能、対応しているエコシステムやコミュニティなど、上で挙げたtree-shakingやminifyも一部モジュールでは優れていても、一部モジュールでは劣っているなど、当然ながら未完成な部分が多いです。
ただ、ある程度の実行テストの結果、勝っている部分もあり、まだやるべきことは（SSL、MCP、CLI、安定化、APIドキュメントなど）たくさん残っていますが、もともとの目標だったReact Nativeアプリのビルドと動作については、商用アプリ3本でリリースビルド、開発ビルド、開発サーバーを確認した結果、問題なく動作することを確認できたので、このあたりで公開して、そのまま開発を続けてもいいのではないかと思い、この記事を書くことにしました。
それでも開発およびバンドル機能（zntcもzntcでビルドして配布しています）はある程度うまく動いており、
必須機能であるデコレーターや、React Nativeで半ば必須の機能であるworklet、typescript、flowなども、テストしたライブラリは問題なく動いています。
vite、rspack向けプラグインも提供しており、vite、rspackのような開発環境も提供し（RN、Web）、ドキュメントもあり、React HMRもあり、モジュールフェデレーションにも対応していて、などなど
それでも一応、バンドラー／トランスパイラとしての基本機能は備えていると思うので、フィードバックもいただきたく、公開後も継続して開発していくつもりです。
手で書いたコードは0で、すべてAIとの激しい議論の中で開発されました。
どんな製品開発をするときよりもAIを酷使した気がします。
Claudeだけを使っていましたが、後からCodexも使いました。
バンドラー自体の開発期間は約3か月（約3000個のPR）、上で話した思考の流れまで含めると、だいたい6か月ほど昼夜を問わず作業しました。
平日も休日も休まず作業し、ほかのバンドラーとの無駄な比較から来る劣等感？のような意識もあって、
test262 100%などさまざまなテストケースを通すために、テストケースも暴走気味と言えるほど大量に書いて開発しました。
たくさんのフィードバックをお願いします (__)
5件のコメント
Metro の代替としては、RSPack や WebPack を使う Re.Pack もあります。
取り留めなく書いていて、書き漏らしていました。
おっしゃる通り、Re.pack もかなり参考にしました。
Re.pack と Rspack はどちらも swc ベースなので、flow をネイティブではサポートしていないと認識しています。
Re.pack の場合、バージョン 5 からは Rspack ベースだと理解していますが、同様に Re.pack も swc+babel を使っているため、flow や reanimated、nativewind（zntc は対応予定）など人気の高いプラグインも、依然として Babel でトランスパイルされていると認識しています。
個人的には Babel から脱却したかったので、zntc ではそれを基本対応のオプションとして実装しました。
zntc も Babel 互換性はサポートしていますが、できる限り babel 依存をゼロにしたいと考えていました。
安定性も高く実績のあるコードではありますが、js という制約上、速度面では常にボトルネックになるので。
実際、開発中もずっと他のバンドラーとベンチマークを比較しながら見てきましたし、自分の目でも継続的に体感してきた通り、当然ながら他のバンドラーに比べると機能や安定性、拡張性で劣る部分があるため、この点は今後も改善していきたいと思っています。
ただ、主要な React Native ライブラリのパーサー互換性などが最初から組み込まれているため、Re.pack ではどうしても発生する構造的なボトルネックの区間については、こちらが優位だと考えています!
簡単ではないプロジェクトだと思いますが、応援しています。
ありがとうございます！！
うーん…test262 100%か……バッジだけ見てV8級かと思いました（笑）