バックエンドのコードもbundle+minifyする
Summary
インスペクタで確認したところ、V8はコメントなども全て含むスクリプトコードそのものもメモリに載せてるっぽく、手元の検証ではそれだけで100MB近くメモリを消費している
そのため、(node_modules内のコードも含め)バックエンドのコードもminifyすればメモリ使用量を大幅に減らせる可能性がある
Purpose
メモリ使用量削減
Do you want to implement this feature yourself?
- [ ] Yes, I will implement this by myself and send a pull request
(本番稼働時、例外発生時のスタックトレースをログに吐いてる箇所がどうなるか(難読化されて追いにくくならないか)がちょっと心配です)
難読化ではなくminifyだから読みにくくはなるけど普通に追うことは可能だわね
あれだったらソースマップ生成しても良いとは思う
.swcrcのminifyをtrueにして試してみたんですが、変数名・クラス名を短縮するまではされてなくて、改行スペースを除いて1行にするだけみたいでした。それなら…まあ
ソースマップなしでminifyはちょっと……と思ったけどソースマップつくならいいかも
ソースマップなしでminifyはちょっとと思われた理由って何でしょう?
エラーログが吐かれるときに、スタックトレースが見づらいと報告するのもされるのも困る
ちなみに、ソースマップはインライン(ファイル末尾にエンコードして埋め込み)で既についてそうです
Misskeyで発生してキャッチされなかったJavaScriptエラーは、そのMisskeyサーバーの運営者が見て対処してもらうものではなくて、(そのまま)Issueなどで報告してもらうことを想定しています なのでサーバー運営者にとってキャッチされなかったJavaScriptのエラーが読みやすいかどうか(変数名などがそのまま見えるかどうか)は重要でないと思ってます。 (仮に運営者がスタックトレースを見て何らかの理解を行うとしても、minifyされていたからといって調査が困難になるかというとそんなことはないと思います。スタックトレースを理解できるほどの運営者であれば尚更)
エラーが報告された側の立場(我々)からしても、少なくとも自分はスタックトレースがminifyされていたからといって調査が困難になるということはないので大丈夫と思います
(ところでサーバー側のメモリってそんなに枯渇するのかな…… jemallocに差し替えてからはかなり余裕あるんだけど)
(フロントエンドはすでにminifyされて提供されていますが、特にエラーの調査に支障をきたしているということも感じてないです)
スクリプトそのままメモリに載せているというのはやっぱり事実っぽい https://stackoverflow.com/a/78796916
(とはいえdevelopment環境などでminifyしないオプションは欲しい)
多分バンドルも同時に行わないとnode_modulesのコードをminifyはできないわね
swc単体ではバンドルできない?
webpackの情報しか出ない
esbuild使えそう
いろいろエラー出る
ネイティブが絡んでる部分についてはこれが使えないかしら https://zenn.dev/junkor/articles/2bcd22ca08d21d#(%E8%A3%9C%E8%B6%B3)esbuild%E3%81%A7packages%E3%82%AA%E3%83%97%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E4%BD%BF%E3%81%86%E5%A0%B4%E5%90%88
あ、でもこれ全パッケージを除外しちゃうのか
こんな感じに設定することでバンドルは成功した
ただ起動すると
Dynamic require of "util" is not supported
エラーがでる
sentry全体をバンドルから除外したら解決した
今度は
systeminformationをバンドルから除外したら解決した
今度は
nestjs全体をバンドルから除外したら解決した
今度は
なんか結局ほぼバンドルできないみたいなことにならない?
なんか設定でDynamic requireをいい感じにしてくれる設定あったりするのかしら