音声書き起こし 1. オープニング 00:00 @spring_raining 00:07 こんにちは。UITの玉田です。今回もUIT INSIDEを始めたいと思います。
UIT INSIDEは、ユーザーインターフェイスとテクノロジーを開発するためのポッドキャストです。
今回はですね、Node.jsのコントリビューターである上野さん
@spring_raining 00:23 をお呼びしまして、先月。はい。発表されましたNode.js 22の内容についてと、最近のNode.jsのアップデートについても 合わせて聞けていけたらと思っております。それでは、よろしくお願いします。
@cola119 00:37 よろしくお願いします。
2. Node.js 22 00:40 @spring_raining 00:40 それでは、Node.js 22についてなんですけれども、リリース自体は先月4月にありまして、もう収録時点でちょっと経ってしまっているので振り返りっていう感じにはなってしまうんですけども、今だと、バージョン22.2まで 出ております。
で、Node.jsのリリースサイクルは、ご存じの方も多いかと思いますけれども、大体毎年4月頃にLTSが、はい、リリースされるという流れになっていて、今年がバージョン22になっております。
@spring_raining 01:09 なので、LTSのサポートで言うと、毎回偶数のバージョンがLTSとして提供されていますが、バージョン18が来年にサポート終了というスケジュールになっていて、 なので、毎年毎年こう新しいLTSが出るという流れになっています。
というわけで、バージョン22について見ていこうかなと思うんですけども、
@cola119 01:33 気になるものそうできますか。そうですね。気になるやつを サクっと紹介できるやつはサクッとして、細かく話したいやつは何個か細かく話していきたいかなと思います。
3. V8のアップデート 01:44 @cola119 01:44 1番JavaScriptに近い部分で言うと、V8のアップデートが行われました。はい。で、バージョンで言うとV8の12.4にアップデートされたんですが、結構開発者に利益がある部分で言うと、 いくつかのJavaScriptの組み込みの方のAPIが増えた部分があるかなと思っていて、Arrayで言うとfromAsync APIが生えていたりだとか、あとはSetオブジェクトとイテレーターに対してもいくつかヘルパー関数というんですかね、例えばSet.intersectionとか.unionといった新しいAPIが追加されました。なので、主に、特にイテレータの部分で言うと、今までイテレーターから1度Arrayに変換してフィルターするとか やる必要があった部分が、イテレータドットフィルターなどが生えたので、直接イテレーターを操作することが できるようになった点は、かなりコードがスッキリしていいかなと思いました。
@spring_raining 02:40 なるほど、ありがとうございます。そうですね、イテレーター、普段使う内容で言うと、結構私個人としてはもうAsync/Awaitがいっぱいって ではあったんですけど。そうですね、イテレーターもこのタイミングでヘルパーがかなり追加されたということで、 これも本当に自分たちで書くコードでも使いやすくなったのかなと思います。あと、
@spring_raining 03:04 Setメソッドですね。これは結構個人的にはめっちゃありがたいところで、すごいユニオンとかインターセクションとか、自分で 頑張って作った記憶が多いので。
@cola119 03:17 そう、今までだと1つ1つ取り出して、そうですね、和集合かどうかみたいなのをやってたんですけど、それがもう自動的にできるようになるんで、かなりコードもスッキリするし、 パフォーマンスの面でも優れてるのかなと思います。うんうんうん。
@spring_raining 03:30 これ、V8のアップデートなので、もちろんそのChromeも。はい、入ってるものにうんうん なっているものになりまので。これで、ようやく私たちが一般的に使える環境で、使う環境で、 かなり普及してきたっていうところでは大きいですね。
@cola119 03:48 はい、そうですね。
@spring_raining 03:50 私、あまりちゃんと説明できる自信がないんですけれども、一応、V8のあともう1つ大きなアップデートとして、Maglevが ありますね。はいはい。どうしましょう。本当にブログの内容をそのまま紹介する感じなってしまうんですけれども、曰く、V8の内部の そのパイプラインの最適化のパイプラインがありまして、で、その中のスパークプラグという
@spring_raining 04:15 最適化とターボファンというところの間に、何かMaglevという新しい最適化コンパイラが追加されますよというものになっております。ちょっとすみませんが、このあたりは
@cola119 04:28 早くなるそうですね。はい。か
@spring_raining 04:30 いないですけど、この辺りは本当に私たちに、全員に恩恵のあるところだとは思うので。
じゃあ、これが一応V8のアップデートによる変更点になりますかね。
4. ESM→CJSの同期的なrequire()のサポート 04:43 @cola119 04:43 これはTwitterとかでも話題になっていたと思うんですけど、ESModuleとCommonJSのインポートの互換性と言いますか。はい。そこが少し改善したという話があって、CommonJSからESModule のスクリプトを読み込むrequire関数を通してインポートするのが、これまではできていなかった部分が条件付きでできるようになりました。
@cola119 05:06 で、その条件っていうのは、そのインポートしようとしているESModuleのファイルスクリプトにトップレベルアウェイトが含まれていないことになっています。これは、トップレベルアウェイトが含まれていると、そのモジュール自体が非同期の処理が必要になるといったことが理由の 大きな理由の1つとして挙げられていますが、トップレベルアウェイトが含まれていなければ、require
@cola119 05:32 関数経由で、はい、CommonJSから読み込むことができるようになります。
@spring_raining 05:38 これもすごい嬉しいですね。
@cola119 05:40 これはかなり
@spring_raining 05:41 ですよ。はい。 結構あれですよね、その、ESMとCommonJS、そのライブラリの提供者側からすると、うんうんうん、両方出すっていうことが多かったと思うんですけども、これによって、一応 今も、今もCommonJSを使っているユーザーもESMも読み込めるようになったので、ライブラリの提供側からしたら、
@spring_raining 06:04 ESMだけで良くなるっていう、
@cola119 06:07 そうですね、はい。CommonJSのことは対してそうですね。特別な対応をする必要がなくなったというものです。
はい。ただ、こちらのエクスペリメンタルなので、フラグ付きで、オプションフラグ付きで、この機能を有効にすることができます。
5. --runオプション 06:25 @cola119 06:26 で、あともう1つはrunオプションが追加されたことですね。npm runと
@cola119 06:33 同様にpackage.jsonのscriptsフィールドに定義されてるコマンドタスクを npmを使わずにNode.jsが実行できるようになるという機能になります。例で言うと、npm run testとかnpm run serveとかをよくフロントエンドエンジニアの実行してると思うんですけど、そこがnode --run、
@cola119 06:57 node --run testとかnode --run startとかにできるようになります。モチベーションと言いますか、 npmでもう既にできているものをなぜコアに入れるのかって話なんですけど、結構1番大きなモチベーションとしてはパフォーマンスの話が あって、npm run経由でスクリプトを実行するのとするのはかなり遅いっていうのが1年前ぐらいから
@cola119 07:26 結構問題として上がっていまして、それが今回のnode runオプションになると大体6倍ぐらい速くなるっていうのが はい上げられています。180ミリセカンドが30ミリセカンドぐらいになるという高速化が期待できますね。
@spring_raining 07:45 それはなかなか大きいですね。確かにそうなんですよね。実装されるからには 何かしらやっぱり違いが、違いというか、こう、改善点みたいなのがあるのかなと思ってたんですけど、なるほど、そんなに速くなるのだったら、かなり違いそうですね。
@cola119 08:00 そうですね。ただ、結構これはプルリクエストが提案された時 に結構議論の的になって、結構盛り上がっていたんですけど、そもそもnpm runとの違いと言いますか、npm runをじゃあコアに全部実装するのかどうかみたいな話が 1つあって、ドキュメントにも書いてあるんですけど、node runの目的としては
@cola119 08:25 npm runの置き換えではないというのは強くドキュメントとかでも書いてあるかなと思います。
あくまで、なんて言うんですかね、サブセットと言いますか、本当にタスクランナーとしての機能を提供するだけであって、npmの置き換えではないっていうのは議論されたんですけど、強く 主張されている部分かなと思います。例えば、モノレポのサポートも全然ないですし、npm runだとpreとかpostっていう、あ、
@spring_raining 08:51 はいはいはい。
@cola119 08:52 名前を最初につけると、その処理の前後で自動的にやってくれるみたいな処理があると思うんですけど、そういった機能も実装される予定はないっていう風にドキュメントでも明言されています。
@spring_raining 09:03 じゃあ、そうですね、結構これ、実装自体も、議論を尽くされたという感じでしょうかね。
@cola119 09:11 そうですね。そもそもこのnpm runが遅いからどうにかしたいっていう話は1年以上前からあって、 で、それをNode.jsで実装しようっていう取り組みは1年前に同様に行われていて、別の人なんですけど、 実際プルリクエストも出されていたんですが、当時はそれ自体は結構POC的な目的が強くて、例えばそのNode.js
@cola119 09:38 で実装するとこれで速くなりますよっていう提起、問題提起がメインだったので、結構議論は盛り上がっていたんですけど、最終的に議論を収束せずにマージまでは至らなかったっていう背景があった。 ありました。それが今年5月に別の人によって再度 再挑戦される、プルリクエストを作り直して再挑戦するような形で、はい、実装が行われました。
@cola119 10:04 で、結構その中では議論が白熱していて、さっき言ったnpmのクローンを 実装する必要はあるのかどうかみたいな話から始まって、こんだけパフォーマンスは重要なのかどうかみたいな話もあったんですけど、 あとは、最初はnode runっていう、
@cola119 10:24 ちょっとも言葉で言うと難しいですけど、runていうサブコマンドを用意するみたいな初期実装だったので、 今はフラグランってフラグなんですけど、node runていうサブコマンドの実装だったため、それは破壊的変更になってしまう ですよね。run。はいはい、難しいね。カレントディレクトリにrun.jsっていうファイルがあると。
@cola119 10:44 はいはいはい。なんで。そう。確かにNode.jsにサブコマンドを実装するっていうのは、かなり歴史的背景もあって、結構厳しいんですよね。
なので、最終的にはこういうフラグ、--runっていうフラグの形になったっていう背景もあります。
ただ、こう、色々議論がされていたんですけど、なんか
@cola119 11:05 結構僕はそこリアルタイムで追ってたんですけど、結局こう、GitHub上の議論だとなかなか収束せずに、こう、コラボレーターサミットっていう、ロンドンで行われた対面での メンテナ、Node.jsのメンテナー同士が集まるような機会がちょうどあったので、そこでこう対面で議論されて、 最終的にはこう、今の形で落ち着いてとマージ、無事にマージされるといった形になりました。
@spring_raining 11:33 なるほど、なんかその話はすごいコラボレーターっぽい話ですね。結局って言い方は悪いですけど、そういう、こう、GitHub上の議論以外にも、そういった、
@cola119 11:43 うん、
@spring_raining 11:44 議論があった上でっていうところだったんですね
@cola119 11:46 そうですね。やっぱりNode.jsはどこかの企業が持っているとかそういったわけではない、コミュニティが完全に運用してるものなんで、やっぱり議論がすごい 発散して、結構はい、どうしようもないみたいなことも結構あるんですけど、やっぱそういう時は 対面で話して投票して決まるみたいなことも結構あります。うん。
@cola119 12:07 実装の話ですけど、最初はこう、JavaScriptでのレイヤーでこのオプションが実装されていたんですけど、その後に C++のレイヤーで再実装されて、さらにパフォーマンスが1.5倍ぐらい向上しました。
これも結構議論の的になっていて、
@cola119 12:25 JSからC++の実装に変えることでメンテナンス、その新規コントリビューターとか、今のメンテナーもそうですけど、 C++の実装のメンテナンスが難しくなるんじゃないかみたいな懸念が結構議論されていました。
@spring_raining 12:41 仕様を考えると、スクリプトを実行するというよりは、むしろ、なんて言うんですかね、そのカレントディレクトリからpackage.jsonを読み出して、 そうですね、scriptタグを、 scriptタグっていうか、scriptオブジェクトを取ってきてっていうところがなんか、なんて言うんですかね、こう、実行するまでの色々とこう、npm runが
@spring_raining 13:02 実装してきた暗黙的な仕様みたいなのを最適化するってのが結構 焦点になりそうなので、それを考えると、いや、確かにJSからC++に実装し直したら早くなるっていうのは 確かになっていう気持ちはあります。
@cola119 13:21 そうですね、結構Node.jsって最近パフォーマンスにも結構力入れてる部分だと思うんですけど、やっぱり C++で実装した方が何事も早くなるんですよね。うん。なんですけど、結構 メンテナンス性とのトレードオフがすごい強くあるんで、
@cola119 13:41 面白い部分でもありますけど、結構将来のことも考えるとどっちにしようかなみたいな議論はかなりあります。
で、今収録中の話。収録中段階だとまだ実装中なんですけど、今は本当に単純にカレントディレクトリのpackage.jsonを見つけて、その中のscriptsフィールドを見るっていう実装なんですけど、 npmには今のディレクトリにpackage.jsonがなかったら、その親のディレクトリを探しに行くっていうトラバースする処理が
@cola119 14:10 あるんですが、それも今回のNode.jsのnode runに入れられないかっていう提案が今まさにされている最中になってますね。
@spring_raining 14:19 そうなんですね。確かそれはあれですね、かなりnpm runに実装近くなる変更ですよね。
@cola119 14:26 そうですね。
@spring_raining 14:27 それは便利そうですね。それがあるだけでもだいぶ、特にモノレポとかだとかなりうんうんうん、便利になってきそう。
@cola119 14:36 そうですね。移行がしやすくなりますね。はい。っていう、結構 最初のモチベーションとしてはパフォーマンスを向上するためだったんですけど、結構議論が白熱してて面白いなというのを見てて思いました。
@spring_raining 14:50 もうすごいあれですね、そのパフォーマンスとその機能、多機能さのバランスの取り方がやっぱり。うんですね、 難しいですね。なんかあまりこうやりすぎると結局npm runになってしまうっていう。
@cola119 15:05 そうですね、
@spring_raining 15:06 あるので。はい。そこはやっぱり色々と議論が尽くされるところかなと思います。
6. Node.js 22 のその他のアップデート 15:15 @cola119 15:15 その他で言うと、Stream APIというNode.jsでよく使われるAPIがあると思うんですけど、それのハイウォーターマーク のデフォルト値がこれまで16キロバイトだったものが64キロバイトに変更されました。うん、なかなかあんまり意識することはないかもしれないんですけど、ハイウォーターマークはその名の通りと言いますか、ストリームの内部で データをバッファーを持っているんですけど、それのバッファを持つ上限値、持つ容量を指定できる部分になっていて、これを値をすごくたくさん上げれば、その分ストリームの内部で
@cola119 15:50 バッファを持つことはできるんですけど、メモリーの制限との兼ね合いもある部分で、今まで16だったんですけど、デフォルトが64に変更されたことでバッファをたくさん持つことができるので、パフォーマンスの向上に期待できるという形になっております。
@spring_raining 16:04 そうですね、このあたりはもう昨今、その64キロバイトって、もうかなりそれでも小さいなっていう感覚はあるんですけども、やっぱりあれですね、一応、その、こう、メモリの 制限の大きい環境だと、結構もしかしたら動かなくなる、不安定になるかもしれないみたいなところもあるかもしれない。
@cola119 16:22 一応、オプション値として設定もできるので、メモリがかなりストリクトな環境の場合は、16とかに下げてみるといいかなと思います。
@cola119 16:32 watchオプション、watchフラグがステーブルになりました。v18時台18.11にエクスペリメンタルとして追加されたオプションで、その名の通り、ファイルの変更を監視して、 ファイルが変更されたらそのファイルの実行をもう一度やり直すというオプションになっております。これがステーブルになったので、一応、ステーブルのエクスペリメンタルの定義の
@cola119 16:54 違いとしては、エクスペリメンタルはまだまだ破壊的変更とか、もしかしたら削除されるかもしれないようなAPIで、ステーブルに関してはプロダクション環境でも十分使える、 今後長くメンテナンスされていくものという使い分けになっているので、もう安心してプロダクション環境で使っていただけるかなと思います。
@spring_raining 17:12 なるほど。ありがとうございます。 実は私、watchオプションもうすでに。はい、使ってて、今までだとnodemonとかそういった。はい。ライブラリを使って使ってたものなんですけども、一応エクスペリメンタルではあったんですけど、基本このオプション使うのって開発時なのかなっていう気はしていたので、使ってたっていうところなんですけど、
@spring_raining 17:34 晴れてステーブルになったというとこですね。これは本当にいいですね。
@cola119 17:38 はい。ぜひ使ってみてください。はい。
@cola119 17:42 それ以外で言うと、WebSocketも同じくエクスペリメンタルからステーブルに変更になりました。
これは。はい。Web APIで定義されてるものと同じインターフェースを持ったWebSocketのクライアントクラスになっていて、グローバルに入ってるものになります。これまでは外部パッケージ を使ってWebSocketのクライアントを使うことが多かったかなと思うんですけど、これを使うことでウェブブラウザと同様のコードで
@cola119 18:06 WebSocketクライアントを書くことができるようになってます。
@spring_raining 18:10 こちらもそうですね。エクスペリメンタルからステーブルになったっていうところですね。
@cola119 18:16 globとglobSyncというAPIがfsモジュールにエクスペリメンタルとして追加されました。
これはちょっと実装内部的な話が。 ていうと、これまでNode.jsの内部の処理で、globの処理は元々ありまして、minimatchっていう外部パッケージを使って
@cola119 18:36 globの処理を行っていたんですけど、それをfsモジュールを経由して外部、我々も使えるような形でAPIとして公開されるようになりました。
@spring_raining 18:45 なるほど、結構そうですね。これも本当に大きなところではありますよね。私は 大体globbyというライブラリで使ってる実装してた記憶がありますけど、これはあれですかね、minimatchというパッケージが内包というか、された形に近いという。
@cola119 19:06 はい、そうです。Node.jsの中にバンドルされるようになって。
@spring_raining 19:10 なるほどなるほど。
@cola119 19:11 一部直接公開されてるわけじゃなくて、一部キャッシュとかの処理が Node.jsのレイヤーで行われてるんですけど。はい。そのさらにglobの本体の処理としてはminimatchが使われているという
@spring_raining 19:21 ことになっています。なるほど、それはいいですね。
@cola119 19:25 で、あと、AbortSignalインスタンス作成時のパフォーマンスが向上したという話題もあります。
7. v22.1.0: NODE_COMPILE_CACHE 19:33 @spring_raining 19:33 では、今までのが一応22.0の。はい。リリース時点でのアナウンスになりますが、実はそれ以降ももちろんバージョンは上がり続けていますので、変更点が 実はあるということなので、せっかくなので22.0以降の機能ですね、いくつか取り上げていただこうかなと思うんですけれども。
@cola119 19:54 そうですね、やっぱり全部は取り上げられないので、ちょっと目玉のやつを取り上げたいんですけど。22.1 から新しい環境変数が導入されまして、NODE_COMPILE_CACHEという環境変数が導入されました。で、これはこれを利用すると、Node.jsが
@cola119 20:14 内部でV8を使ってソースコードをコンパイルした結果をディレクトリにキャッシュすることができるようになります。
で、このキャッシュを使うと、次回以降、キャッシュされた後のスクリプトの立ち上げの速度が向上するということが期待できます。
この環境変数に、はい、キャッシュのディレクトリを指定することで、オンディスクにキャッシュを持つことができるようになります。
@spring_raining 20:39 これはあれですかね、環境変数を指定しないと有効化されないタイプの機能ですよね。
@cola119 20:46 うん、そうですね。環境変数で明示的にキャッシュ先を指定し、キャッシュの保存先を指定しないと有効にはならないやつになります。
結構面白いですね。
@spring_raining 20:57 2回目以降の、そうですね、実行される時のことなんですね。これは。そうですね、結構早くなりそうですね。
@cola119 21:05 やっぱり最近のNode.jsも、DenoとかBunが出てきて、出てきたあたりからパフォーマンスに結構フォーカスが当たるようになってきてるなっていうのをすごい感じていて、こういう キャッシュとか、さっきの話もそうですけど。はい、結構パフォーマンス向上の
@cola119 21:25 機能追加が多いなっていうのをすごい感じます。
@spring_raining 21:28 ただ、あれですよね、 あくまでオプトインって感じは。うんうんうん、やっぱりそうそうそう。なんかこれもそうだったんですね。結構。やっぱり互換性を保ちつつも早くしようっていう、はい ところはやっぱりNode.jsらしい
@cola119 21:48 気はします。はいはいはい。いや、そうですね、確かに。あと、エクスペリメンタルで入る ので、基本的にはそのエクスペリメントの時に、結構破壊的変更とかも入れつつ、ユーザーのフィードバックを反映して、1度ステーブルになれば全然 全く破壊的変更が行われないので、
@cola119 22:10 そこはちゃんと、そこはしっかりと、利用する際にはエクスペリメンタルかどうかみたいな部分は確認してから利用するといいかなと思います。
8. v22.2.0: --inspector-waitフラグ 22:19 @cola119 22:20 で、最後22.2のリリースで、ちょっと自分の話かもしれないですけど、自分が実装した話なのでちょっと 詳細ぜひ紹介したいなというものがあるんですけど、新しいフラグが導入されまして、
@cola119 22:34 --inspect-waitというフラグが導入されました。これはNode.jsのアプリのデバッグ時に利用できるオプションなんですけど、 この--inspect-waitフラグを有効にして Node.jsを実行すると、Node.jsがデバッグを有効にした状態で立ち上がるので、Chrome DevToolsを接続して
@cola119 22:55 デバッグ情報を見ることができるようになる機能になります。コンソールログとか、あと最近だとパフォーマンスも Chrome DevToolsを使って取ることができるようになったりだとか、ブレイクポイントを置くみたいな処理もできるので、是非このフラグは利用して 見てほしいなと思います。
@cola119 23:13 元々デバッグする機能自体はあるんですけど、--inspect-waitフラグはその名の通りですね、DevToolsが接続されるまで、DevToolsが開かれるまでNode.jsの処理を止めておくという機能になって。
@spring_raining 23:28 いや、それすごい便利そうじゃないですか。なんかインスペクターもは元々あれ。そうですよね。メリットなので。
@cola119 23:36 そうですね。--inspectっていうフラグもあるんですけど、そっちも同様に。
@spring_raining 23:41 なるほどなるほど。
@cola119 23:42 はい。アプリケーションをデバッグモードで立ち上げるんですけど、それはDevToolsの接続を待たないで スクリプトを実行し始めるんで、なんか例えば5秒で終了するようなスクリプトのデバッグが難しいっていう問題が あるんですけど、このフラグを使っていただければ、接続されるまで処理は進まないので、本当にスクリプトの先頭からデバッグ情報を取る、
@cola119 24:05 ログを取るとか、そういったことができるようになります。
@spring_raining 24:08 そうですよね。なんか、あらかじめ、なんかDevToolsを起動させておいてとか、そんな感じでした。
@cola119 24:14 そうですねとか、デバッガーっていうコード書いて、あ、はいと強制的に止まるようにしておくみたいな。
@spring_raining 24:19 っていう感じでする
@cola119 24:21 と、置いておくみたいな。はい、そういうの必要なくできるので、うん、ぜひ、最新版ですけど、ぜひ 利用してみてください。すごい。
@spring_raining 24:32 ちなみに、この機能は、こう、バックログとかにある感じなんですか。ちょっとNode.jsの話になると思うんですけど、これは、
@cola119 24:42 いや、
@spring_raining 24:43 自分で機能を提案したんですかね。
@cola119 24:46 そうですね。元々課題意識は持っていたんですけど、その、さっき言ったスクリプトが先に走っちゃうと、 デバッグ、先頭からデバッグするの難しいみたいなのは、結構ユーザーとしては感じていた部分なんですけど。
で、ただ、その解決策はちょっとわかんないなと思っていたんですけど、結構、他のDenoとかBunには元々--inspect-waitっていうフラグが導入されて
@cola119 25:09 ましての実際ないっていう状態だったので、 実装しようという風に至った経緯ですね。特にバックログに積まれていたとか、イシュー報告されていたわけではなかったです。本当にNode.jsは 本当に欲しい機能があれば実装してから議論しましょうみたいな雰囲気もあるので、全然、特に何をやるとか何をやらないとかはそういうのは決まってない。
@spring_raining 25:32 結構あれですね、ほんとにこれもなんかこう、プルリクエスト作る前に何かやったっていうわけでもない。
@cola119 25:39 そうですね。本当にですね、いきなりというか、リクエスト送ってレビューお願いしますって言ってレビューしてもらったっていう感じですね。
@spring_raining 25:49 おお、いいですね。 ありがとうございます。じゃあ我々も何かこう気になるところを見つけて出せば、まあまあそうそう簡単ではないと思い、
@cola119 26:00 コントリビュートの1つの方法としてありま。それ以外に、なんか結構ここ不便だなとか思ったらイシュー立ってるフィーチャーリクエストってイシューが あるので、はい、イシュー立てるだけでも全然反応伺えるので、そういう始め方でもいいかなと思いますね。ぜひ フィードバックがウェルカムなので、ちょっとコントリビューション難しいなって場合は、イシューを立てるところから始めてみてもいいかなと思います。
@spring_raining 26:25 ありがとうございます。じゃあ、私も改善点を見つけて
@cola119 26:31 ぜひ。はい。あと、特に今回のエクスペリメンタルの機能とランオプションとかは 全然まだまだ議論の余地のある部分かなと思うし、破壊的変更全然まだ可能なので、ガツガツ提案できるような エリアかなと思います。
@spring_raining 26:47 ありがとうございます。
@cola119 26:47 取り上げたいのはこれぐらいかなと思います。
@spring_raining 26:51 では、エンディングに移ります。
9. クロージング 26:53 @spring_raining 26:53 今回はNode.jsバージョン22と、あとそれ以降のアップデートについて話していきました。LINEヤフーのフロントエンド組織UITでは、このような技術的なキャッチアップを日々行っております。UITインサイド以外にも、毎週様々なフロントの情報交換を行っています。
@spring_raining 27:11 今後もUITインサイドを通して、このような情報を外部に発信していけたらと思います。
最後に、このポッドキャストに対する感想がおありでしたら、#UIT_INSIDE でつぶやいていただきますと、スタッフが拾います。
エピソードのご意見やご感想など、いつでもお待ちしております。それでは、ありがとうございました。
@cola119 27:32 ありがとうございました。