Live data from Hacker News

Turbopack, the successor to Webpack

vercel.com

241–250 of 331 posts

Re: Turbopack, the successor to Webpack

#241

Earlier quoted context omitted.

Why would you want your tooling to be coupled when it doesn't have to be with zero downside?

I outlined some of the downsides in the comment, more in another comment of mine. I thought about it even more and I think I can finally see the possibly true reason why people are developing these type of bundlers: The typescript projects that they have to work on are so huge that the typechecking is always going to be too slow so you don't want to deal with it, you rather typecheck only the file that you're current…

Typescript has an open bug to use multiple threads for compilation.

That's why it's slow. It's also not a big deal because of parallel type checkers.

> Yes I really don't think that omitting typechecking is the way to go for development.

You've not really given a reason why. Just a rant about how other languages are different.

Re: Turbopack, the successor to Webpack

#242

> Currently, migrating to Turbopack from Webpack is not yet possible Bummer! Do I need a turbopack.config.js? I've still got my package.json, tsconfig.json, .env, and postcss.config.js apparently. > [Turbopack cannot currently be configured with plugins. We plan to make Turbopack extensible, likely with an altered API] Will I be able to use my current plugins? Where does config for these plugins live? > [SCSS and LES…

What's wrong with SCSS modules? It has a lot of really useful functionality that frontend developers like me love.

They still require a preprocessor. Let's push to get that stuff into CSS! Worst case run `npm install sass`.

Re: Turbopack, the successor to Webpack

#243

Earlier quoted context omitted.

Running the typechecker independently of the bundler is really common in TypeScript. Typechecking takes time, and blocking on it to transpile and bundle your JS doesn't really add any benefit. Most build systems run the checker in parallel because it cuts down on build time. Plus, Webpack doesn't really do transpiling or typechecking for you — your loaders do. Webpack's loaders can't really check your types because,…

>Running the typechecker independently of the bundler is really common in TypeScript maybe it is common, I can't speak to that but in my opinion a large part of the success of webpack was probably because they bundled the typechecking. Because that's the only workflow that makes sense, imagine a c# compiler that quickly outputs executable IL code but half the time it's broken because it didn't do any type checking an…

No, webpack became popular because it was the only bundler that supported commonjs and handled code splitting reasonably well, so we picked it for React.

It's critical to run type checking outside of webpack. You should be able to execute code that does not type check correctly. It maximizes iteration speed and is one of TypeScript's key superpowers.

Re: Turbopack, the successor to Webpack

#244

Earlier quoted context omitted.

Running the typechecker independently of the bundler is really common in TypeScript. Typechecking takes time, and blocking on it to transpile and bundle your JS doesn't really add any benefit. Most build systems run the checker in parallel because it cuts down on build time. Plus, Webpack doesn't really do transpiling or typechecking for you — your loaders do. Webpack's loaders can't really check your types because,…

>Running the typechecker independently of the bundler is really common in TypeScript maybe it is common, I can't speak to that but in my opinion a large part of the success of webpack was probably because they bundled the typechecking. Because that's the only workflow that makes sense, imagine a c# compiler that quickly outputs executable IL code but half the time it's broken because it didn't do any type checking an…

JavaScript is a dynamically-typed language. Parallelizing the type checking with bundling gives you the best of both worlds: the speed when writing in a dynamic language and the type safety that comes with a static-typed language. For me, I like to write my code and not too concern myself with types until I’m close to committing; that’s when I fix type errors.

Re: Turbopack, the successor to Webpack

#245

These bundlers do not do the same work as webpack. Turbopack is using swc for typescript which means it will not do typechecking during compilation which effectively makes it fairly useless as a compiler. Now, if you only want bundling and minification then sure but why would anyone want only bundling? Good luck having a sensible workflow when your type checking has to run separately and perfectly match whatever type…

No post body was provided.

Re: Turbopack, the successor to Webpack

#246

Earlier quoted context omitted.

Running the typechecker independently of the bundler is really common in TypeScript. Typechecking takes time, and blocking on it to transpile and bundle your JS doesn't really add any benefit. Most build systems run the checker in parallel because it cuts down on build time. Plus, Webpack doesn't really do transpiling or typechecking for you — your loaders do. Webpack's loaders can't really check your types because,…

>Running the typechecker independently of the bundler is really common in TypeScript maybe it is common, I can't speak to that but in my opinion a large part of the success of webpack was probably because they bundled the typechecking. Because that's the only workflow that makes sense, imagine a c# compiler that quickly outputs executable IL code but half the time it's broken because it didn't do any type checking an…

Webpack does not bundle the type checking by default - iirc it cannot handle typescript at all by default, it needs to be configured.

The typescript plugin that you used may have included type checking, but it very much depends on how you set it up. Many common setups use Babel to compile typescript code, which doesn't do any type checking at all, just mechanically strips away the type signatures. I would be very surprised if much of webpack's success has come from the type checking functionality you describe.

As for whether it's "the only workflow that makes sense", I find the most comfortable flow for me is using the compiler as a linter rather than a "true" compiler. It runs in my IDE, potentially as a pre-commit script, and in CI (which means checked in code cannot fail to type check), but I can still build failing code. This would be, as you say strange if I were using C#, but syntactically valid typescript can always be covered to syntactically valid javascript, so the output won't be "broken" in the same way that a C# program with invalid types would be. Most of the time, a program that isn't accepted by TSC is still a valid javascript program, just with poorly specified input and output types.

That said, while it can be useful occasionally if I'm still trying to figure out the types, the advantage here is less that I can now compile invalid code, and more that my bundler doesn't need to do unnecessary type checking. Any errors I can catch myself based on the red squiggles in my editor, so I know not to look at the browser until I've fixed all the issues, and at that point I don't need my bundler to also confirm that the types are accurate. Each tool does one task well. (Similarly, I don't want my bundler to also run all the unit tests before it compiles, even though I would normally expect the tests to be passing before I check the output of my code. 90% of the time, if I run the bundler, my tests are passing, and in the last 10%, I probably want to quickly try something out without changing the tests. The same logic usually applies to my types.)

As a result, I strongly disagree with the claim that your process is the only one that makes sense. It may be the most logical for you and your team, but I tend to find that it makes sense to approach typescript from a different angle to most typical compiled languages, and I've found a lot of success in my process.

Re: Turbopack, the successor to Webpack

#247
post #81

From my experience working with esbuild since it's early days, all I can say is to that there has been a very high bar set by esbuild's speed and ease-of-use. I've used it for all my web apps and services since and i've finally begun to like my front-end build chain, unbelievably.

esbuild is great, but our only blocker for using it was that there was no way to control the number of chunks. On a moderately sized modular app, this can slow down things significantly[0]

[0] https://github.com/evanw/esbuild/issues/2317

Re: Turbopack, the successor to Webpack

#249
post #212

Wow remote caching like Bazel is wild to see in a bundler. It's nice to see someone realize that JS bundling is more or less like compiling and linking in the native code world and we just need to accept it and optimize the hell out of it.

Does it make sense to cache something that takes 1.7 seconds though?

Yes. The nice thing about Bazel is that it'll also be able to do the same caching and cache invalidation across your build graph, so for a decently sized project the savings can be much bigger. I think [0] gives a decent overview.

[0]: https://blog.aspect.dev/rules-ts-benchmarks

Post reply on HN