Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Turbopack, the successor to Webpack

vercel.com

Post reply on HN
Print view View original

191–200 of 331 posts

Re: Turbopack, the successor to Webpack

#191

Post by rtpg »

lelandfe wrote: post #169
adamparsons wrote: post #168

Earlier quoted context omitted.

Just migrated one of our projects from webpack+babel+tsc to just webpack with esbuild-loader, the difference is astounding. Just need to remove webpack itself now so we can use their transforms.

Doesn't esbuild skip Typescript type checking? https://esbuild.github.io/content-types/#typescript You'll still need to keep tsc around for that, though perhaps you're doing that with another step in Webpack...?

You don’t need webpack to run tsc. You can treat typescript as a linter and run it seperately (it also has a fast watch mode)

Re: Turbopack, the successor to Webpack

#193

Post by fragile_frogs »

rsanheim wrote: post #60

Looks impressive, but proof will be in the actual day to day dev experience and configuration, not the perf. Vite and esbuild are fast enough, and I feel the winner will be more about usability, docs, easy config, etc. That aside, it is just so frustrating and sad that this just continues the fragmentation in the JS build space. It is beyond exhausting at this point. I don't care about vite vs (or with) esbuild vs tu…

> I just wanna `script/build` or `yarn dev` and not think about it anymore.

Parcel might be a good fit for you: https://parceljs.org/

Re: Turbopack, the successor to Webpack

#194

Post by nickjj »

ksec wrote: post #20

I am wondering if Rails moved to esbuild a little too early.

The Rails https://github.com/rails/jsbundling-rails gem lets you pick between esbuild, rollup and Webpack. If Turbopack ends up being popular then jsbundling should be able to support it.

The nice thing about Rails now is there's no massive direct integration like Webpacker once was. Now we can basically use the JS tool straight up and Rails will just look at assets in a specific directory, it doesn't matter what tool generated it.

Re: Turbopack, the successor to Webpack

#195

Post by samhuk »

lelandfe wrote: post #169
adamparsons wrote: post #168

Earlier quoted context omitted.

Just migrated one of our projects from webpack+babel+tsc to just webpack with esbuild-loader, the difference is astounding. Just need to remove webpack itself now so we can use their transforms.

Doesn't esbuild skip Typescript type checking? https://esbuild.github.io/content-types/#typescript You'll still need to keep tsc around for that, though perhaps you're doing that with another step in Webpack...?

It does, but esbuild helps with hot-reloading speed.

You just have your tsc compile as a pre-commit git hook and CI pipeline step.

Re: Turbopack, the successor to Webpack

#196

Post by lelandfe »

rtpg wrote: post #191
lelandfe wrote: post #169

Earlier quoted context omitted.

Doesn't esbuild skip Typescript type checking? https://esbuild.github.io/content-types/#typescript You'll still need to keep tsc around for that, though perhaps you're doing that with another step in Webpack...?

You don’t need webpack to run tsc. You can treat typescript as a linter and run it seperately (it also has a fast watch mode)

Parent comment said they went from "webpack+babel+tsc" to "webpack with esbuild-loader"

The lack of tsc in the new process made me wonder if it just got added to Webpack

Re: Turbopack, the successor to Webpack

#197

Post by fragile_frogs »

pelagicAustral wrote: post #15

This now has really started to feel like the last days of Rome.

I think this might have just made their lives easier, from the projects website:

> Rome is designed to replace Babel, ESLint, webpack, Prettier, Jest, and others.

Since both projects are written in Rust, the Rome team could use Tubopack to build/bundle projects and focus on the other features they are planing: https://rome.tools/#supported-features

Re: Turbopack, the successor to Webpack

#198

Post by cantSpellSober »

> 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 LESS] don't currently work out-of-the-box with Turbopack

Keep it this way! LESS has been dead and SCSS dying. Focus on CSS Modules please!

Re: Turbopack, the successor to Webpack

#199

Post by fragile_frogs »

cercatrova wrote: post #52
arvigeus wrote: post #34

Earlier quoted context omitted.

Turbopack is just a bundler, while Rome is the whole package. I think only Deno strives for the same, but still can’t replace things like eslint

Sure, but Rome is being eaten by the other things Vercel has, such as SWC replacing Terser and Babel. Pretty soon all of Rome's niches will be already met by other tools, I'd wager. I think Rome simply does not have a large and well-funded enough team compared to Vercel and others like Vite.

I think this could benefit Rome. Both projects are written in Rust and so far they have a linter and a formatter and now they can integrate Turbopack, package it behind "rome build" and don't have to build their own bundler and transpiler.

Re: Turbopack, the successor to Webpack

#200

Post by andrew_ »

domoritz wrote: post #109
no_wizard wrote: post #84

Really hope this gets a competent library mode. Webpacks library mode never really evolved to meet the needs of things. Vite has a good library mode but it has its own limitations. Pure rollup is still the best for building libraries, by and large (maybe esbuild now? but I think rollup is more efficient in its output still). If this has a good, solid library mode that works like rollup with the power of the webpack-l…

Yes. I mostly build libraries and rollup still beats everything in compatibility (esm, umd, cjs, etc) and output quality. It's slow, though, and I would love a faster alternative. Esbuild doesn't do tree shaking as well as rollup.

Vite uses it under the hood and has it running crazy fast.
Post reply on HN