音声書き起こし
1. オープニング
@spring_raining
こんにちは、UITの玉田です。今回もUIT INSIDEを始めたいと思います。
UIT INSIDEは、ユーザーインターフェースと、テクノロジーを愛する開発者のためのポットキャストです。
最新のウェブ標準の動向や、開発フレームワークの変遷、
UIやUXに関することまで、毎週フロントエンドの情報を発信していくことを目的としています。
今回はですね、えっと、まあ、皆さんご存じのViteについて取り上げようと思います。で、えーViteまあ、結構 前からちょくちょく取り上げてるんですけれどもま、今回改めて意図について話を聞いていこうと思います。でえ、今回はですね。えっと、え本さんと
@spring_raining
えこのさんのお2人をえお呼びして、この3人で話していこうかなと思います。それでは、よろしくお願いします、
@kazushikonosu
よろしくお願いします
@T28_tatsuya
よろしくお願いします
2. 最近のViteの普及
@spring_raining
か。Viteを取り上げると、直接のまあきっかけはVite 3が出たから取り上げようかなという ところなんですけども、どんな感じに今Vite使ってますかね。とか、そういったところをえ、聞いていこうかなと思います。で、えっと、過去に えUIT INSIDEでViteを取り上げた例で行きます。と、えっと、エピソード93が、えっと、フロントエンドツーリングについての
@spring_raining
え、UITミートアップがありましたので、ま、それのアフターショーで、まあ、Viteについて話したりとか。
あとは、えっと、エピソード90で、えっと、23秒のビルドが23msにLINEバイトにおける、Snowpack導入記という タイトルのえ、エピソードを公開しましたこれはあれですかね。あの、今3この時もえ出ていて、で、えっと、この時はまあSnowpackを
@spring_raining
導入したっていう結論だったと思うんですけど、ま、あれからこう時間がたち、どういった感じになってるかっていうところも、ちょっと今回聞いてみたいと思います。
で、そうですね、あのマリーと結構まあここにいらっしゃるみさんは、使っているViteバリバリ使ってるんじゃないかなと 思うんですけれども、結構もう割と普及しましたよね。うん
@spring_raining
しましたよね、なんか、どれぐらいの割合で使ってるかとか、ちゃんと把握してないんですけれども。でも、周りもうなんか大体 いつの間にか使ってるっていう感じになってるかなと。
@T28_tatsuya
なんか、普通の普通に選択肢の1つとして上がってますよね。名前とかはまあ当然ですけど、これ使うみたいな、使ってる、使ってるみたいな、 新しいツールっていうよりは、もう普及したツールっていう印象がありますよね。
@spring_raining
そうですよね、そうですよね、なんかあんまりこう昔だとなんかすごい冒険してるなかな、 うん、うん感じの印象だったかもしれないですけど、全然そんなことはもうなくなっていて。そうですね。
結構ここ1、2年で変わったなという
@T28_tatsuya
印象だけ、そのコンセプトも結構新しい方じゃないですか。そのバンドルしないみたいな、そういうところで、よりこう先進的な印象はあったと思うんですけど、 だいぶそれもみんな慣れてきたったっていう感じなんですかね。
@spring_raining
そうですよね、まあ、あのネイティブesmとかま、そういったところの普及とかもあって、結構コンセプトが 受け入れられてきたかなと思いますね。じゃあ、そうですね、あの、それぞれのメンバーのViteの導入 状況みたいなのを聞いていこうと思います。
3. @kazushikonosuの導入事例
@spring_raining
じゃあ、ちょっとどうしましょう。なんか、私から話すのもあれなんで、 じゃああれですね。あの、エピソード90で、あのSnowpack導入されてたっていう話をしてた おのさんなんですけれども、あれからどうなったかとか、今どんな感じかとか教えてもらえますか。
@kazushikonosu
えっと、エピソード九州の時点では、まだViteが当てたってぐらいの時で、SnowpackとViteを比較して、 なお、Snowpackを導入したんですけど、あれからSnowpackはピートに追い上げられて、今じゃ もうメンテナンスもされてない状況にしまいました。
@spring_raining
そうですね、
@kazushikonosu
で、えっと、最近LINEバイトの方では、React 18にアップグレードしたんですけども、そのタイミングで と、そのパックがメンテナーされてないので、そのパックでこう修正するのであれば、まあ、せっかくだから、Viteを導入しようかっていう話になって、 ほんと最近Viteを導入した感じです。
@spring_raining
あれですね、あの、React 18のアップグレードの話が、それはそれでめっちゃ気になる
@spring_raining
そうですね。Snowpack、Snowpackは なかなかま残残念っていうか、Snowpackのチームが今、Astroの開発にもう完全に移っちゃってるんでっていうのがあるんですけど、もそうですよね、 なんか、もっとこう並立するのかと思ったら、もうVite一強にいつの間にかなってたっていう感じですね。うん、
@T28_tatsuya
あの、Viteのドキュメントも面白いですよね。部人の時は、そのSnowpackがこう1番おっきい比較の対象だったんですけど、 vさんのドキュメントになった瞬間も、1番下にちょろちょろって書いてあるだけみたいになってて、
@kazushikonosu
うん、もうもう戦う相手じゃないっていう感じなんで。
@spring_raining
なるほど、そっか、そこらへんにドキュメントも変わってるんですよね。
@T28_tatsuya
そうですね、部2から3にかけて、なんかこうリニューアルしましたみたいなのが、記事にも上がってましたよね。
@spring_raining
そう、ドキュメント後で紹介するんですけど、日本語のドキュメントにもあったりとかしてましたね、じゃあ、 あれですかね。なんか、あの意向についてこう困ったこととか、導入の具体的な内容とか教えてもらってもいいですか。
@kazushikonosu
はい、えっと、LINEバイトだとと、Next.jsとかではなくて、1枚でサバーサイドレンタリングを行っていて、Snowpackの時は、Snowpackのドキュメントで、このサーバーサイドレンダリングのやり方とか、詳しく説明されていなかったんですけども。Vite 2では結構ドキュメントで、パワーサイドレンダリングについても、詳しくは使っていてと、むしろ移行はとてもしやすかったなっていう感想です。
@kazushikonosu
それ以外も結構Snowpackといって、すごい思想が似ていて、 こう設定とかも言っているので、そんなにこう意向でつまずいたところはなかったかなと思っています。
@spring_raining
なるほど、いや、意外意外っていうか、まあでもそうですね、目的は似てるっていうところはありますね。あと、あれですね、サーバーサイドレンダリングを 来てるってのは、特徴というか、なかなか大変そうだと思ったんですけど、そこも大丈夫だったんです。
@kazushikonosu
そうですね、それこそReact 18でrenderToStringじゃなくて、streamを使ったサバーサイドレンダリングに移行したんですけども、 Viteだと、その辺も全く問題なく、すごい順調にこうすることができまし。
@T28_tatsuya
ssrってエクスペ。あの、実験的な機能みたいな感じだったと思うんですけど、なんか困ったことってほんと全然なかった感じなんですかね。
@kazushikonosu
こう話す話すことがなくて、逆に何もな。
@kazushikonosu
何もなく、スムーズにできてしまって、むしろこ
@T28_tatsuya
そうなんだ、ちょっとUIT INSIDE的には聞き応えはないですね。
@spring_raining
なんか、もっとみんなこう苦労してる話を聞きたいのかなと思ったんですけど、全然
@T28_tatsuya
でもドキュメントもしっかりしてるし、いいですよね。
@kazushikonosu
あ、そうですね、ドキュメントがしっかりしてるっていうのと、あと、多分Snowpackを導入するときに、えっと、ogで書かれてるものをすぐに移行したりとか。
結構そこで色々と対応してたので、ま、あんまりケースとしてはないと思うんですけども、SnowpackからViteに移行するっていうケースにおいては、 すごいやりやすいんだろうなっていう風に感じました。
@spring_raining
そうですね、あと、
@spring_raining
集まったことがないという
@spring_raining
サーバーサイドエンダリングはあれですかね、その開発向けだけなんですかね。それとも、そのプロダクションも、サーバーサイドレンダリングをやってるんですかね。
@kazushikonosu
あ、えっと、Snowpackの時もそうだったんですけど、もとバイトでは、開発の時は、Viteなリスのパックなリーを使っていて、 プロダクションの時は、Webpackを使ってバンドルしてます。なのでと、サブファイド については、プロダクションの時も、開発の時もどっちもサーバーサイドレンダリングはしてるんですけども、ちょっと方法が違うっていうような状況ですかね。
@spring_raining
ああ、なるほど、なるほど、そこはィブアップなんですね。
@kazushikonosu
そうですね、
@spring_raining
結構サーバーファイドレンダリングの実装が開発環境と本番で違うってのは結構なんかあの難所ポイントかなと思ったんですけど、
@kazushikonosu
こただ、あのViteについては、テンプレートみたいなものを用意して、 それに、あのViteのapiがスクリプトタグをインジェクトするみたいな。apiのインターフェースになってるんですけども、それがすごくいいなと思って、 あの、Webpackでも、自分であのスクリプトタグをインジェクトしておいてっていうことができるので、こう
@kazushikonosu
エンダラーについては、共通化して、Viteと、えっと、Webpackの環境の場合は、エントリーポイントを変えるだけで対応するみたいなことができたので、 ここまでこうコードが別になるってことはなくて、すごいやりやすいなっていう風に感じました。
@spring_raining
あ、なるほど、いいえ、すごいスムーズに行ってそうで、羨ましい
@spring_raining
その、なんて言うんすか、ビルドの差によって、なんか困ったこととかもないんですかね。
@kazushikonosu
一応、あの、ただそのViteを使ってるって言っても、結局Babelのプラグインを使いたいっていうモチベーションがあって、 Babelはいをかばしてるので、そこまでこうビルトに差が出るみたいなところは、今のところ、そういう問題は発生してないです。
@spring_raining
うん、うん、うん、うん、ま、それを考えると、ほんとになんかリルドしてる通路が違うだけって感じ
@kazushikonosu
え、早いっていう、もう何も言うことなしっていう感じです。
@spring_raining
いや、ありがとうございます
4. @T28_tatsuyaの導入事例
@spring_raining
じゃ、山本さんはどんあれですかね。えっと、防衛空港だと思うんですけど。
@T28_tatsuya
えっと、僕はoaクーポンでVite使ってるんですけど、バイラインバイトみたいに、こう置き換えとかではなくて、uiのリニューアルのタイミングで、ちょっと 割と1から実装を作れたので、ビルトツールも再検討できたので、じゃあ、ちょっとVite使ってみっかみたいな流れでやりました。
なので、その移行に関するつみとかはあんまりなくて、で、先ほど言った通り、ドキュメントもしっかりしてるので、まあ、普通に使う分にはなんなく
@T28_tatsuya
っていう感じですね。目的は、結構開発体験の方の工場のみみたいな感じになっちゃってて、 一応Viteってその開発中もいいです。モジュールに関してこう爆束でやるっていう風になってて、で、プロダクションビルドも色々こう考えられてると思うんですけど、 プロダクションのビルドの時だけは、えっと、残念ながらちょっと。インフラ側の都合で、javascriptとかをおっきい1つのファイルにして、
@T28_tatsuya
配信っていう構造になってるんですよね。なので、えっと、使うモチベーションとしては、その開発体験の部分だけなんですけど、現状は まあその観点で見てももう十分早い。
@T28_tatsuya
開発サーバーとかの軌道も爆速なので、すごく助かってるなと思ってますね。
で、さっき、そのインフラの都合で、プロダクションビルでは、jpスクリフト1個にあま、正確には2個なんですけど、にしてます。この コードスプリッティングできてません。っていう話をしたと思うんですけど、で、それが具体的に言うと、その
@T28_tatsuya
デプロイのタイミングで、ベースのパスurlのパスがこうデプロイのタイミングで決まるので、ビルドで確定しないから。あの、 ちょっといわゆるドキュメントViteロド、キュメンタリーに書いてある、バックエンドインテ、グレーションみたいな感じのものができないっていう都合なんですよね。
で、実はvさんのアップデートで、この課題が解決しそうなので、早く更新したいっていう風になってて、
@T28_tatsuya
v2だと、そのベースパスとかは、そのビルドのタイミングでViteに渡してあげると、それに合わせてこうコードスプリッティングされたファイルも
@T28_tatsuya
そのベースパスに応じてこう非同期で読み込むみたいのがあるんですよね。
で、それは固定値なので、固定の文字列なので。えっと、さっき言ったoaクーポンみたいに、配信時にベースパスが決まるみたいな話だと、ちょっとできない なんだけどvさんまだvさんでも、まだ確かエキストラメントなんですけど、
@T28_tatsuya
タイミングでは、その動的にその辺解決できる仕組みを入れてくれるみたいなので、 なんでいよいよ。そのViteのプロダクション側での旨味みたいなも使えそうで、僕はとてもワクワクしております。
@spring_raining
なるほどな、
@kazushikonosu
じゃあ、現状だとウィートじゃないものを使って、プロダクションのビルで押してるってことですか。
@T28_tatsuya
いや、えっと、現状はえっと、コードスプッティングさせないように、Viteでビルルしてます。
@kazushikonosu
ああ、なるほどですそうなんですね、
@T28_tatsuya
と、確かファイルサイズだったかな。何かしらのルールを持って、そのコードスプリッティングとかを制御できるんですけど、その辺をちょっと分けないでねっていう風に、 Vite側に設定を渡してます。
@kazushikonosu
なんか、プロダクションビルドだと、Webpackでこう細かく使える設定とかが使えないのか、 ちょっと懸念としてあったりするんですけど、そこは問題なく、プロダクションでもViteを使うって判断寄せれたってことですかね。
@T28_tatsuya
ああまあそうですね、えっと、コードスプリ とさせるとなると、そのバンドラーの実装とか、そういうところで懸念が出てくるかなとは思うんですけど、えっと、単一のjavascriptにしちゃうので。
えっと、そこに関しては、もうテストを通せればオッケーかなっていう判断をします。
@kazushikonosu
あ、そうなんです
@T28_tatsuya
なるほど、はい、あの、なんかすごい小細工を入れつつ、コードスプリッティングさせて。みたいな ことを考えると、ちょっとViteでビールドバンドルはちょっと尊敬かなって思うんですけど、もう単一のものにさせてしまうので、まあ、もちろんWebpackと成果物はちょっと変わるとは思うんですけど、 テストの範囲でとせるかなと。
@kazushikonosu
確かに、1からやるってなったら、プロダクションでもビーと採用できて、すごい羨ましいなって思いました。
@T28_tatsuya
まあ、その分でかい時あまあでかいと言っても、大家クーポン自体がページ少ないからってのもあるんですけど、 あの少ないから、まあ、1つのジェンスでもいいかなって、ちょっと妥協したとこはあるんだけども。本当はちゃんとそのスピッティングのせて、非同期で読み込ませてとかやった方が ピートのまみもありますもんね、
@spring_raining
ここはあれですよね、そのまあ理風特有
@T28_tatsuya
ああ、そういうのまあありますよ確かに
@spring_raining
ありますよね、うん。
@T28_tatsuya
一応、バックエンドインテグレーションっていうページがあって、あの、その何htmlとかを、例えば、javaのサーバーとかで返却してるような インフラの構造も向けにもこう色々仕組みはあるんですけどね。と あるんですけれど、えっと、v2時点ではちょっと僕のプロダクトでは、ちょっと使えないと
@spring_raining
そうですよね。あの、Vite 3の話はまさしくあれですよね、こういったところに使いそうっていうところですよね。
今だと、そのなんていうか、ベースっていう設定で、その絶対パスを 一律で決めてっていう感じだったと思うんですけど、もま、これがアセットのタイプによってりとか、あと、相対パスも使えるんですよね。いや、それは
@spring_raining
我々の事情ではあるんですけど、この相対パスが使えるっていうのは、かなり大きい
@T28_tatsuya
めちゃくちゃですよね。
@spring_raining
うん、ちょっとこれは、私もあの調べてすごい楽しみにしております。
あと、あの開発体験の向上のために導入したっていうところもあるんですけど、これも まあ普通になんか重要というか、導入の理由になるんだな、な、なるよなと
@T28_tatsuya
思いました。そうですね、きっと。まあ、大クーポンは別にプロダクト自体もそんなコードベースもちっちゃいので、嬉しみはそう比較的少ないのかもしれないんですけど。
まあ、それでもデブサーバーをさっさと起動するのはとても嬉しいので、そこだけでもそこだけを目的にしても全然ありだなとは思いますね。
@spring_raining
いや、それは大きいですよ。某Webpackのプロジェクトは、開発サーバー立ち上げに5分10分かかってうーんって感じなんで。
@spring_raining
いや、そうそうなんですよ、いや、これは買いがたいそうですね、
@kazushikonosu
それこそ、LINEバイトも、あのSnowpack導入前は数十秒開発サーバーが立ち上がるなかかって、Snowpackで 改善できて、まい。でも、同じように回転できて、やっぱり全然違うので、それだけでも導入する価値があったなって思います。
@spring_raining
そうですね、やっぱりなんていうんですかね、すごい無駄が多いんだなっていうのが、そのSnowpackとか、Viteとかのうんやつを見て、 そうほんとに思いましたね。その起動して、初めてそのライブの依存ビルドっていうのを始めるのを、 なんかそれはそれで効率が悪いというか、なんかそんなあの、その時点でリードして間に合うんだろうかっていうところがあったんですけど、でも、
@spring_raining
全然ほぼ使ってないんだなみたいな、うん、そういったうんところとか あと、あれですね。えっと、そのま、ライブ側がasm提供してたら、そもそもビルをせずに済むみたいなところとかま、そういったところも、こう 利用して、あれだけ早くなってるんだなっていうところは、まあ、これはなんかViteっていうよりは、
@spring_raining
そのかい。最近のesmの環境のメリットではあるんですけど、でも、や
@T28_tatsuya
こうブラウザーのネイティブの機能を前提としたツールっていうところも、なんか、新しい時代の幕開けがありますよね。
@spring_raining
確かにそうですよね、もとも、
@T28_tatsuya
そのバンドラーとかだって、そのブラウザー色んなのがあるから、もう人の集めにするしかないよね。とか、いろんな都合があるわけですけど、 ネイティブのき、ブラウザーの機能を使うことで、こんなに良くなりますよ。みたいなのはとてもいいと思う。
5. @spring-rainingの導入事例
@spring_raining
じゃあ、まあ一応私もそのViteプロジェクトで使ってるんで、その話をすると、 あれですね。ちょっとあのなんですかね、目的がちょっと違ってて、私のプロジェクトの場合だと、Viteをその なんですかね。ウェブサイトで読み込ませるJSじゃなくて、あのライブラインとして提供するためのあの
@spring_raining
ものとして開発してるんですね。で、えっと、その元々のプロジェクトがあの流通であの全然 違うものなんですけど、もま、今後、将来的にまいろんなプロジェクトでコンポネントを 使いたいという。まあ、具体的に言うと、例えばこうボタンとかなんてすか。モーダルとか、そういったコンポーネントをえっと、
@spring_raining
読み込ませるためのパッケージとして開発しています。でま、それの開発として、 ライブライン自体はそのWeb componentとして提供してるんですけど、もま、それをビルドするためにイートを使ってるっていう感じ なってます。なんでちょっとあれですね。なんか、こうあんまりサーバーサイドレンダリングとか。そういったあの話題とは関係ない感じになってしまってるんですけれども
@spring_raining
で、そうですね、まあ、ただあれですよね、あの、Viteってすごい 偉くてこい。こういった場面の時のために、ライブラリーモードっていうのがあるんですよね、あれ、すごい便利ですね。
好きなので、あの、そのフライがりをえ、コンポーネント。まあ、モレっぽになってるんですけれども、
@spring_raining
それそれぞれのコンポーネントはViteでビルドしてで、えっと、そのまあ依存とかもあるんですけども、それは、あのターオーレコー っていうものを使って管理してるっていう感じになってて。そうですね。じゃ、Vite結構デプロトのまま使ってるのかもしれない。
ちょっと、あの、あのバンドル語の名前をこうカスタマイズしたりとかはしてるんですけど、それぐらいで
@spring_raining
割と。なんか、スノートの機能をそのまま使ってなんとかなってるって感じですね。
@kazushikonosu
でも、設定しなくていいなら、それが1番
@T28_tatsuya
ですよね、それが一番確かに
@kazushikonosu
めんどくさいので。
@T28_tatsuya
あ、オクポのそのビューのプラグインViteのビーのプラグインをそのまま使って、ほぼおしまいですね。
@spring_raining
うん、そうなんですよ、なんか、あの移行移行っていうか、そのなんて言うんすかね。すでにあるプロジェクトを移行させる場合だと、そのなかなかそういう ビルドもViteに移行させるっていうのは、なんかいろんな事情でできなかったりするんですけども そうですよね。私とか、妹さんの場合、そのぶれ新規の開発になってくるので、それはあのまあ
@spring_raining
そもそもなんていうんですかね。こうデグれが起きないっていうか、動かないのが、まあ最初からわかるんで、なかなかイコールしやすいっていうのはありますね。
ただ、ほんとになんかね。まあ、自分たちの問題っていうよりは、多分こう依存しているライガリが使えないとか、そういった感じの話になってくる。
@T28_tatsuya
うん、そうですよね、 それこそ、Viteさんのプラグプラグインとかもそうだし、Vite以外のコアコアの実装以外の部分ってか、コンパチクリティとかもありますもんね。
@spring_raining
そうですね、まあそこはなかなか難しい問題っていうか、まあ今気強く直していく感じになるのかなっていう。
@T28_tatsuya
あ、でも、なんか、Viteの範囲だと、Viteのエコシステムの範囲だと、ちゃんと足並み揃えて3対応してます。みたいなのが、ちょっとドキュメントに書いてあって、 感心しましたね。ちゃんと、プラグViteのプラエコシステム周りでちゃんと共有しているから、このViteさん が公開されました。みたいな記事のタイミングで、プラグインとかももう対応してるよみたいなことが書いてあって、すごい
@T28_tatsuya
安心して使わせていただきます。って感じですね、
@spring_raining
いや、いいですよね、結構ピート3が結構なんて言うんすかね、まあ、あんまり変更が大きくない のかなっていう、ちょっと気はしてる。あ、そういったところもって、結構スムーズに行けてるのかもしれない。ただ、なんかすごいなんていうか、 内部的な変更は結構ありそうなので、そこはすごいですよ。
@T28_tatsuya
Vite 2とか3で、なんか大きく変わりました。みたいなのは、そんなない印象が僕もありましたね、試しになんだっけ。ドキュメントの Why Viteっていうページがあるんですけど、そこのv2とv3でdiff取ってみたんですけど、あのほとんど変わってなかったです。
ちょっとした言葉、尻が数か所編言い方がちょっと変わっただけで、
@T28_tatsuya
あの、そのViteの導入させるモチベーションの大事なポイントみたいなのは、変わってないですね。まさん
@spring_raining
はいはいはい、
@kazushikonosu
消えたのは、Snowpackの言及だけってことですか。
@T28_tatsuya 24:
けど、下の方にすって追いやられてる。
@spring_raining
いや世知辛いただあれ、あの内部的な変更は結構なんて言うんすかね。
あの、そのバーバージョン3に上がった時っていうよりは、確か2.9とかも。結構。それはそれなりにおきか た気がしてて、その依存とかの管理方法がだいぶなんか変わったりとか。
@spring_raining
あの、ちょっと見た時は思ったんですけど、タイプスクリプト4が出てきた時みたいな感想けましたね。そんなになんか深い意味はないけど、 マイナーバージョンが2桁になる前に、バージョン4にしました。みたいな、
@spring_raining
なんか、Viteなんか2.1出すなさ出しとくかみたいな。
あの、ドキュメントか、ドキュメントとか結構買ったんですけど、そんな感じを受けましたね。
@T28_tatsuya
なんか、より宣伝させるために、ちょっとapiも含めて変更が入りました。みたいな感じで、 もう全然違うものやけみたいなメジャーアップデートではないって印象がありますね。
なんか、ウェブの標準と衝突させるのを防ぐために、ちょっと書き方変えますよ。とか、なんだっけ、WebAssemblyだったかな。
@spring_raining
はいはいはいはい、確かに
@T28_tatsuya
そうかより宣伝されていったなっていう印象が。あと、ポート番号とかか。はいはい、
@spring_raining
じゃあまあそれぞれのプロジェクトのバックグラウンドは、結構話せたかなって感じですかね。うん、なかなか。まあ、それぞれの Vite 3に対する思いを持つ 後で聞かせればと思います。じゃあ、はい、次に行きますね。はい、
6. Vite 3の新機能や変更点
@spring_raining
で、えっと、まあ、ちょくちょくとVite 3の話が出てきたかなと思うんで、まあ、もうちょっと具体的に変更点をいていこうかなと思います。で ま、結構なんて言うんすかね。あの、ググったりとかしたら、Vite 3の変更点みたいなロがいっぱい出てきたんで、あんまり
@spring_raining
ここで喋るだろうなっていう気はしてて、 あ、ただあの取り上げるんですけれども、なんかこう。もし、なんか注目のところとかがあれば、後で教えてもらいです。たいですで、 えっと、そうですね、あの、Show noteの方に軽く
@spring_raining
まとめようと思うんですけれども、まずは日本語ドキュメントが公開されたりっていうところとか。ま、Viteスとは関係ないんですけど、ドキュメントが公開 されてます。というところですねあとは、まあ羅列なんですけれども、ポート番号が 5173にかかります。というデポートのポート番号はわかります。というところとか、あと、これ全然
@spring_raining
あの知らなかったんですけど、import.meta.globというのが、あのViteでは露出してて、それを使ったら、 あの動的にインポートできるっていうこれは知らなかったです。なんかあれですねさ、普通にこれ使ったらなんかサーバーサイドレンダリングとか そうピンチ分割とかめっちゃできる。
@T28_tatsuya
うん、めっちゃ便利そうです。僕もちょっと使ったことはないんですけど、結構Viteの特徴的な機能だと思うんで、ちょっと使ってみたいんですよね。
@spring_raining
なんか、その気になれば、普通になんかNext.js的な感じの使い方もうんできそうだなって思いました。
あとは、ssrビルドのものがあって、それの出力がデフォルトでesmになりました。っていうところで、 えっと、ちょっと。まあ、認識があやふやで申し訳ないんですけど、あの、そのモジュールを
@spring_raining
他のモジュール依存してるモジュールをあのビルドするか、そのまま使うかっていうあの判定をえ、エクスターナルとかで、 エクスターナルっていう設定でやるんですけど、もま、それを多分あのデフォルトesmになったことで、 いろんなモジュールをそのビルドすることなく使えるようになったっていう認識です。多分、合ってると思います
@spring_raining
っていうところなんで、まあ、要するにあれですね。そのノードのバージョンも、その あのミニマムのノードのバージョン要求バージョンも上がったので、ま、そういったところもできるっていうところも多分あるのかなと思います。で、 あとあれですねあの、ベース関連、これはさっき話した私たち大望の相対、パス
@T28_tatsuya
ソタイパスの話ですね
@spring_raining
して可能になりました。というところと、あ、えっと、エクスペリエンタルという位置付けなんですけれども、 そのファイルの例えば、エクステンションとかタイプを見て、えっとでアセットのえっと、ベースを出し、開けられるっていうことが できるようになるそうです。つまり、あれですね、そのアセットのタイプによって、その別々のcdnを使ったりとかっていうところができるようになるって感じですね。なんか、
@spring_raining
これはすごい待ち望んでいる人が多そうな機能ですね。で、あとは、 開発地だけでなく、ビルドジもesビルドが使用可能にというところですね。これもあれですね、ちょっと あのすでに使ってる人は結構勇気いるこうかもしれないんですけど、
@spring_raining
これこそあれですね。あの、これからフィート3導入しようっていう時はます。もう、なんか、早い早くなって、 悪いことない感じがしますね。うん、うん、いや、いいですねあとは えっと、これはあれですかね。あの、プラグイン開発者向けかなと思うんですけれども、あの、ホットモジュールプレイスメントって、その
@spring_raining
コードが変更された時に、どうやって、そのコード変更を。えっと、今のあのウェブサーバー上であの 反映させるかっていうところの管理がもう少し細かくできるようになりました、というところがあります。
これも、エクスペリメンタルということで、バーシャルアクセプトなんですかね。という名前で、イペアがここは壊されてます。
@spring_raining
はい、あたりが追加されているそうです。じゃあ、なんか気になる機能とか、 会ってみたい機能とかあったりしますかね。
@T28_tatsuya
あの、言うの3回目ですけど、僕は爽快パスなんですけれど、
@T28_tatsuya
あの、いきなり余談の話をしちゃって申し訳ないんではいすけど、なんでポート番号5173なのかなって気になって、ちょっととかプリのいてみたんですよ。あ、はい。
そしたら、なんかプレビューサーバーのポート変更が、その前さ、デブサーバーの前にあって、4173ってのがあったから5、173にします。みたいなプリを見つけてはい で、ちょうどそのプレビューサーバーのポートを変更するタイミングで、ちょっとポート番号変えないみたいな議論が議論があって、
@spring_raining
うん、うん、
@T28_tatsuya
その流れで決まったみたいなんですよね。で、なんかその辺のプロリック。多分、ショノートの犬になって書こうかなと思うんですけど、結構面白くて、
@spring_raining
うん、
@T28_tatsuya
あの、読んでみた方がいいかなと思うんですけども。あの、ちなみに5173っていうのは、はい、その デートアルファベットでvitって書きますけど、あれをラテン文字とか活用して書くと、数字の5173に見えるっぽいみたいな
@spring_raining
ああああ、なるほどあれですかね。あの、
@T28_tatsuya
ていうことを言ってる人がいて、いや、でもそれ無理がねえかみたいなこと、い
@spring_raining
ま半分こじつけ感がありますね。
@T28_tatsuya
いや、まあ要するに今ま今v2は3000番ですけど、まあ3000版だとちょっとぶつかっちゃうし、不便だよね。みたいな っていう話があって、で、まあ、ポート番号って別にこう厳密なルールっていうか、こう慣例とかであるじゃないですか。あの、邪魔のサーバーだと、8080が多いみたいな。
え、それにのっとってViteもかなりこうユーザーも多いossになったわけだし、こう。独自の番号を付与してもいいんじゃないの。みたいな 話に出てて、
@T28_tatsuya
でま、そういうので、なんやかんやってこの数字になったみたいです。
@spring_raining
なるほど、
@T28_tatsuya
だから、なんか割と身も負担もない数字な気がしたんですけど、それを狙っているっていうか、議論の結果そうなってるみたいですね。
いきなり余談の話をしてい、
@T28_tatsuya
これマってやつだ。
@spring_raining
なんか、個人的には普通になんかからなくて、よくよかったって良くなったっていうぐらいしか思ってなかったんで。なるほど、 確かにtがなのはちょっと無理合いすぎないじゃないですかね。
@T28_tatsuya
でいいよ、ラテラテン文字っていうのかな、やるとこう逆のみたいなかあ、はいはいはい、左右逆みたいな感じになって3ぽくなる。あ、あみたいな でビーとはvだから
@spring_raining
なんかでん電話番号のごろ合わせみたいな
@T28_tatsuya
ふふそうそうそ。
@T28_tatsuya
でも、これ見つけた時はこれなんてなったんだろうなって思うとちょっとふふってなります。
@spring_raining
いいですね、なるほどこさんはなんか注目の機能というか、
@kazushikonosu
あ、僕が気になったのは開発時だけじゃなくて、ビルドジボesビルドを使うみたいなところで、
@spring_raining
ああ、はいはいはい。
@kazushikonosu
今後、プロダクションビルドもesビルドを使う。流れになっていくのかなって思うと、ちょっと興味深いなって思いました。その 結構、今のバイトとかだと、Babelのプラグインとかにすごく深く依存してるので、 こうイエスビルドで、プロダクションビルドまでやるっていう流れになると、ちょっと移行とかは大変そうだなと思
@spring_raining
うん。これはそうですよね、なんか、あんまり 今回の件とは関係ないのごい、あの、ViteはRollupを使ってるから、すごいなんか なんていうんですかね。こう、移行しやすさみたいなのを売りにしてたんですけども、ここの変更はあれですよね。まあ、
@spring_raining
こうそこをある程度広報感性みたいなのを犠牲にして、もうちょっとこう早くしみたいな、 あの印象ではあれですね。そのNext.jsにこう対抗してるのかなっていう 感じをちょっときましたね。あの、SWCをどんどんNext.jsがあ、導入していってるので、
@spring_raining
対抗っていうか、なんかそうですよね、あの、早くしようと思い始めてるのかなっていうところですね。うん、
@kazushikonosu
なんか、結構Babelの資産が色々あるので、それとはこう今後どうなっていくのかなって思ったり、今後Viteがもっと一般的になってきたら、 そことの兼ね合いもあると思うので、すごい注目したいなと、
@spring_raining
いや、でも、なかなか長い道のりかなという感じは受けますね。
@T28_tatsuya
あれ、まだ部員さんの段階だとローラップなんでしたっけ。
@spring_raining
ああ、ちょっとそのあたり。
@spring_raining
RollupはRollupで設定できると思うんですけど。あ、そうですよね。なんか、そのオプティマイゼーションが、 あのesビルドでどうなんだ。
@spring_raining
すいません。Rollupと言いすぎると、両方使ってるものだと思ってたんですけど、いや、でもなんか optimize dependenciesとか書いてますね。じゃあ、Rollupつか使わないんです。
うん、なんか、Vite4になる前にみたいな、そんな感じなんま、今後その可能性はあるところ。
@spring_raining
いやすいません、すごい歯切れが悪くて、
@T28_tatsuya
あの素朴に聞いちゃっただけなんで、みんなでコメント見ましょう。
@spring_raining
はいじゃ 読みましょう、
@spring_raining
いや、でもなんかあれですね、すごいま全体的な感想としては、すごい結構あのま、Snowpack の時だと、結構なんていうんですかね。ま、ある意味割り切りというか、その開発時の デブ環境しかサポートしません。みたいな感じの印象受けてたんですけども、やっぱりVite 3を見ていくと、どんどんなんていうんですかね。こう
@spring_raining
両方ちゃんと対応しますし、あの 1ホットモジュールプレスメントも対応しますし、サーバーサイドレンダリングもよりますし、ウィルドもちゃんとサポートします。みたいな着を 感じてすごいあれですね、ちゃんとエコシステムを作ろうとしてるな、という、
うん、うん、うん、うん、気持ちを止めます。
@T28_tatsuya
ビルビルドツールとして、ガチで取りに来てる感じがしますよね、好きがない印象を持ちました。
@spring_raining
そうですよね、まあ、なかなかそうですよね、こう、Next.jsとかがこう対頭してきて、 こう全部みたいなのが出ると、そういったなんか1機能だけみたいなのがなかなか難しくなってくるのかなと
7. クロージング
@spring_raining
えというわけで、今回はえーVite3や。えっと、それぞれのプロジェクトでのViteの導入事例について聞いていきました。
LINEのフロントエンド組織UITでは、このような技術的なキャッチアップを日々行っております。UIT INSIDE以外にも、 毎週の社内勉強会で、フロントエンドの情報交換を行っています。今後も、UIT INSIDEを通して、
このような情報を外部に発信していきたらと思います。
最後に、現在、LINE株式会社では、新卒中途採用とに大募集しています。
このポットキャストを聞いて、LINEに興味を持たれましたら、Show note1番下にある求人ページから、ぜひアクセスしてください。
それでは、このさんやまさん、ありがとうございました、
@kazushikonosu
ありがとうございます。
