MENU
  1. ホーム
  2. javascript
  3. turbopack vite webpackの比較おすすめ(モジュールバンドラーの種類)

turbopack vite webpackの比較おすすめ(モジュールバンドラーの種類)

javascript

「モジュールバンドラ」、「ビルドツール」、「JavaScriptバンドラ」、「フロントエンドビルドツール」と呼ばれるものの覚書です。

エックスサーバーのお友達紹介プログラム!

turbopack vite webpackのの比較おすすめ(モジュールバンドラーの種類)

これらのツールは、JavaScriptやCSS、画像などの静的リソースを一つまたは複数のバンドルにまとめる役割を果たします。また、依存関係の解決、トランスパイリング（ES6以上のJavaScriptをES5に変換するなど）、ミニファイケーション（コードの圧縮）、console.logの削除などのタスクも行います。

Webpackは非常に成熟しており、多くのプラグインとローダーが利用可能で、高度にカスタマイズ可能です。しかし、設定が複雑で、ビルド速度が遅いという欠点があります。WebPackはたくさん人が使っているためサポートは続くでしょうが、Tobias Koppersさんは、Next.jsを開発するVercelに移籍してTurbopackの開発に力を入れていることは確かです。基本的に開発終了の流れでしょうから、新規では使いたくありません。

Viteは開発時のホットモジュールリプレースメントが非常に高速で、設定が簡単であるという利点があります。また、ビルド時にはRollupを使用しているため、小さなバンドルサイズを実現できます。ViteのライセンスはMITライセンスです。開発者はVueの開発者であるEvan You(イヴァン・ヨー)さんです。美術大学卒業してGoogleに入った少し変わった経歴ですね。その後、Vue、Viteと開発しています。

Turbopackは新しいツールで、Rustで開発されており、ビルド速度の向上と大規模なアプリケーションに対する対応力が強化されています。しかし、まだβ版の段階であり、全ての機能が完成していません。turbopackはMPLライセンスです。ソースコードの変更を公開する必要があるという条件が付いていますが、それ以外は自由に使用、コピー、修正、マージ、公開、配布、サブライセンス設定、そして/または販売することができます。開発者はTobias Koppersさん。

スポンサーリンク

turbopack vite の口コミ

turbopackがviteより10倍早いとでていましたが、マーケティングはヤバいことが話題になっていましたね。

 it’s often better to listen to the creators/developers than aggresive marketing departments.

https://github.com/yyx990803/vite-vs-next-turbo-hmr/discussions/8

この意見には同意です。

現実的に開発されているアプリケーションのモジュール数を考えた場合、両者の性能を比較してTurbopackがViteよりも非常に優れている、と結論づける根拠がない。

https://recruit.gmo.jp/engineer/jisedai/blog/turbopack-vs-vite/

静かなるインターネットでもVitestを使っていますね。

ライブラリとしてはVitestとReact Testing Libraryを使っています

https://zenn.dev/catnose99/articles/f8a90a1616dfb3

個人的にもviteにしました。

個人的にもviteにしました。Turbopackの開発状況は今度注視していく必要があるでしょう。

スポンサーリンク

Viteとesbuild

JSの圧縮とconsole.logのみであれば、esbuildがよさそうです。esbuildとViteは別物ですが、Viteはesbuildを含んでいます。

esbuildでCSSのPNGパスエラー

JSと一緒にCSSも圧縮しようと思ったのですが、CSS内にPNGパスがあるとエラーで通りませんでした。

loaderを設定すると、通るのですけど、出力先に画像がコピーされてしまいます。やりたいこととちょっと違います。

loader: {
  '.png': 'file',
},

無視してくれればいいのです。ignore: [‘.png’],みたいなのがいないかと思ったらありました。externalだったため気付きにくかったです。

external: ['*.png'],

参考！

The solution to this is to pass *.png as external as indicated:

https://github.com/evanw/esbuild/issues/800

You can mark a file or a package as external to exclude it from your build. 

https://esbuild.github.io/api/#external

取り去るというのはCSS内ではなく、画像を生成でず取り去るみたいなニュアンスでしょう。圧縮されたCSSはpngは残っていたので。

you can use *.png to remove all .png

https://esbuild.github.io/api/#external

こちらはGPT４君では解決できず、自力解決。少し難しいものはやっぱこうなりがちですね。ぐぐりましょう！

esbuildのクロスプラットフォームエラー

Windowsで使っていたVsCodeのプロジェクトをMacに共有した場合に問題が起きました。

Error: 
You installed esbuild for another platform than the one you're currently using.
This won't work because esbuild is written with native code and needs to
install a platform-specific binary executable.

Specifically the "@esbuild/win32-x64" package is present but this platform
needs the "@esbuild/darwin-arm64" package instead.

解決策は公式サイトに提示されていました。

Simultaneous platforms

You cannot install esbuild on one OS, copy the node_modules directory to another OS without reinstalling, and then run esbuild on that other OS. This won’t work because esbuild is written with native code and needs to install a platform-specific binary executable. Normally this isn’t an issue because you typically check your package.json file into version control, not your node_modules directory, and then everyone runs npm install on their local machine after cloning the repository.

However, people sometimes get into this situation by installing esbuild on Windows or macOS and copying their node_modules directory into a Docker image that runs Linux, or by copying their node_modules directory between Windows and WSL environments. The way to get this to work depends on your package manager:

npm/pnpm: If you are installing with npm or pnpm, you can try not copying the node_modules directory when you copy the files over, and running npm ci or npm install on the destination platform after the copy. Or you could consider using Yarn instead which has built-in support for installing a package on multiple platforms simultaneously.

Yarn: If you are installing with Yarn, you can try listing both this platform and the other platform in your .yarnrc.yml file using the supportedArchitectures feature. Keep in mind that this means multiple copies of esbuild will be present on the file system.

You can also get into this situation on a macOS computer with an ARM processor if you install esbuild using the ARM version of npm but then try to run esbuild with the x86-64 version of node running inside of Rosetta. In that case, an easy fix is to run your code using the ARM version of node instead, which can be downloaded here: https://nodejs.org/en/download/.

Another alternative is to use the esbuild-wasm package instead, which works the same way on all platforms. But it comes with a heavy performance cost and can sometimes be 10x slower than the esbuild package, so you may also not want to do that.

https://esbuild.github.io/getting-started/#bundling-for-node

MacとWindowsをDropboxで同期したため、発生した問題でした。

node_modulesを各々わける必要があります。

Windowsでプロジェクトを使う可能性が低かったため、node_modules_winというフォルダ名を変更してバックアップを取り、Mac環境でnode_modulesを再インストールするというシンプルな解決策で問題解決しました。

npm install

ご参考になれば幸いです。

スポンサーリンク
javascript
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

コメント

コメントする