For me, Turbopack resulted in faster builds but also non-recoverable errors on syntax errors.
Turbopack: Building faster by building less
21–26 of 26 posts
Re: Turbopack: Building faster by building less
#22Re: Turbopack: Building faster by building less
#23This is a good write up on the workings. However, in actual use, Turbopack has severe limitations when compared to Webpack. I’ve been working on https://jsonquery.app and rely on the jq WASM dependency for the queries. But, Turbopack cannot handle importing a WASM binary or the glue code for it directly. The workaround is to have a script copy the binary to the public directory. But that's not all. jq-wasm has a depe…
`fs` dependencies like that have caused issues before. the solution is typically something like
``` turbopack: { resolveAlias: { fs: { browser: './empty-module.js' }, }, }, ```
so different configuration but similar to what you would do in webpack.
i am unsure about the other wasm issue you mentioned... is there an issue describing it?
As for webpack, we will keep supporting it until we know there are no compatibility issues blocking people from migrating.
Re: Turbopack: Building faster by building less
#24The fact that there's no tangible plan for any plugin support in Turbopack is actually what made me not choose Next.js. The answer for people who need basically any build plugin is "use the webpack mode", and I have zero faith in Vercel maintaining that past the next major version. I guess we'll see whether they figure out a story for plugins by then.
Vendor lock-in. Next.js is great until it's not.
it is true that our plugin story is not fully fleshed out. We have good support for webpack loaders and have observed that that solves many (though not all usecases). This of course is one of the reasons we are still supporting webpack
Re: Turbopack: Building faster by building less
#25Much less indeed, not all Webpack plugins capabilities are supported and now anyone that wants to make one has to learn Rust, which surely isn't the same as writing it in JavaScript. The splitting communities effect always gets left out of these announcements, or gets positioned as something good.
We have invested a lot in webpack loaders which unblocked manmy ecosystem plugins. We don't particularly plan on creating a rust plugin API, when we do provide one it will be JS oriented. (well some people are interested in a wasm plugin layer, but we would always support JS first).
I'm not sure i understand your second comment? what got positioned as 'something good'?
Re: Turbopack: Building faster by building less
#26For me, Turbopack resulted in faster builds but also non-recoverable errors on syntax errors.
interesting. we had some reports like this of 'stuck errors' when filesystem caching was still very experimental, or back before we achieved 'stable' status. What version was this on?