Turbopack: Building faster by building less(nextjs.org)

Turbopack: Building faster by building less

https://nextjs.org/blog/turbopack-incremental-computation

25 comments

This 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 dependency on the ‘fs’ module, even though no fs functions are used. But trying to resolve this in Turbopack is not possible and 2 days of fighting this was a waste of time.

Webpack solved this problem with a few lines in the next.config.ts

For now, I’m back to using Webpack with NextJS 16 with the —Webpack flag. Hope they allow this for future versions.

There are plenty of complaints on the NextJS subreddit, and here is a open thread on complaints with Turbopack https://github.com/vercel/next.js/discussions/77721

Looks the alternative is Rspack?

lukesandberg6 ay önce

`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.

tkzed496 ay önce

The 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.

razodactyl6 ay önce

Vendor lock-in. Next.js is great until it's not.

lukesandberg6 ay önce

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

augusteo6 ay önce

The technical approach here is solid. Fine-grained dependency tracking with automatic invalidation is the right way to do incremental compilation. The Rust implementation means it can actually handle large codebases without the JS runtime becoming the bottleneck.

But the skepticism in this thread about ecosystem fragmentation is valid. Vite won because it worked with the existing ecosystem, not against it. Turbopack requiring Rust for plugins limits who can extend it.

That said, if you're already locked into Next.js, this is a clear win. The question is whether Next.js's market position justifies a separate build tool or whether this accelerates the trend of frameworks becoming walled gardens.

I personally love Vite and Remix.

brylie6 ay önce

I may be out of the loop, but isn't the JS/TS community consolidating around Vite?

https://vite.dev/

rk066 ay önce

turbopack is tightly coupled with next.js

rest of the JS community can't use turbopack, so they went with vite

gempir6 ay önce

Kind of weird way to put it. Turbopack was not a real product for years. It was forever stuck in weird beta/alpha stage and only recently went and became the default for NextJS.

Vite has been stable for years at least 5 years now and is built-upon because it's fast, stable, reliable and a bit less complicated than Webpack.

brylie6 ay önce

Thanks for the clarification.

icyJoseph6 ay önce

(1)

[deleted]6 ay önce

o_m6 ay önce

Yes, TurboPack is for legacy projects that can't update from Webpack, but still want some bundle speed improvements.

chrisldgk6 ay önce

Which is mainly NextJS (old and new), since under the hood that still seems to rely on Webpack.

pjmlp6 ay önce

Not really, because they only ported into Rust the most used plugins with "yes but" constraints.

pjmlp6 ay önce

Much 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.

lukesandberg6 ay önce

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'?

baby6 ay önce

Using nextjs with turbopack in a turborepo+bun monorepo is so hard. Someone need to explain to me how things are supposed to be setup

> Many build systems include explicit dependency graphs that must be manually populated when evaluating build rules. Explicitly declaring your dependency graph can theoretically give optimal results, but in practice it leaves room for errors

Man this is the part I hate with turborepo

maelito6 ay önce

For me, Turbopack resulted in faster builds but also non-recoverable errors on syntax errors.

lukesandberg6 ay önce

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?

lloydatkinson6 ay önce

Not to be confused with Turborepo.

almaight6 ay önce

This thing can't be replaced by bun on Linux.

chrisldgk6 ay önce

Is this a quip I’m not understanding or is there really something here that bun‘s bundled wouldn’t be able to do? Because I can’t find anything.

pjjpo6 ay önce

Not to say it is the quip but I have had buggy builds with bun that requires sticking to esbuild, I think it was bundling prettier with many plugins into a single JS file.

I always do that sort of thing in Docker so never considered it could be a Linux-specific thing, maybe so.