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

181–190 of 331 posts

Re: Turbopack, the successor to Webpack

#181

Post by VoidWhisperer »

fragile_frogs wrote: post #174

After years of configuring webpack for various projects I have finally decided to migrate all my projects to Parcel[1] manly because I got tired of creating and maintaining hundreds of lines of webpack.config.js files, I wanted something that just works. I am really happy with that decision. Parcel is plenty fast and is pretty much zero config, I can use it to build libraries[2] as well as applications[3] for the bro…

This has been a huge frustration of mine with webpack - you end up with relatively complicated configs and it sometimes feels like even if you copy and paste your config over, you end up still having to spend a ton of time fighting with webpack to actually get it to work

Re: Turbopack, the successor to Webpack

#182

Post by noahtallen »

jscheel wrote: post #111
djbusby wrote: post #93

Earlier quoted context omitted.

By my count its 23 years. The biggest issue in FOSS is folk don't wanna join a "good enough" project and move it. Sometimes the project is contributor hostile (rare?) And we end up with basically: "I'll build my own moonbase with blackjack and hookers!" All that starting from scratch costs loads of impossible-to- recover-time.

Well, that's what is really frustrating here. Turbopack is built by the creator of Webpack. So, instead of fixing the bloated megalith that webpack has become, they are just moving on to greener pastures. But this time it'll be different™

I mean, there’s really only so much you can do. If major changes are required, you can either make a significant new version with massive compatibility issues, splitting the community (ala Python 2 & 3). And even then, you’re still building off of the old code.

Or start from scratch and make something better.

Either way, you split the community, but at least with the new tool you can (hopefully) manage to make it a lot better than a refactor would have been. (In some areas, anyways.)

Plus, this allows the old project to continue on without massive breaking changes, something its users probably appreciate. And this old project can still create new major versions if needed, which is something you don’t get if you have a major refactor because everything meaningful gets shipped to the refactored version.

So I think spinning off a new project is a net good here. It doesn’t impact webpack very much unless people ditch it and stop maintaining it (unlikely). It lets them iterate on new ideas without maintaining compatibility. (Good, when the big issue with webpack is its complexity.)

So if the idea turns out to be bad, we haven’t really lost anything.

Re: Turbopack, the successor to Webpack

#184

Post by simlevesque »

moron4hire wrote: post #175
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...?

During hour to hour development, I just let Visual Studio tell me about the errors as they come up. On the rare occasions I don't already have the editor open before deploying, I have a shell script to kick off the right tsc invocation. Otherwise, bundling plus uploading to the server is just another shell script. Yes, a full type check from scratch is slow, but it doesn't come up that often.

To anyone who wants to do this:

Let's say you have a tsconfig.json. Create a tsconfig-test.json like this:

    {
        "compilerOptions": {
            "noEmit": true,
            "skipLibCheck": true
        },
        "extends": "./tsconfig.json",
        "include": ["./\*/*.ts", "./\*/*.d.ts"]
    }
Add a script to your package.json (I use "test-types")

    ...
        "scripts": {
            "test-types": "tsc --project ./tsconfig-test.json",
    ...
Then you can "yarn test-types" quickly. I use husky[1] to run that command as a git pre-commit hook. My team cannot commit Typescript errors. Additionally I have a strict tsconfig and a strict eslint config (with these plugins:sonarjs, @typescript-eslint, simple-import-sort) which prevents "any" types and bad typescript hygiene. Results in faster code reviews.

[1] https://www.npmjs.com/package/husky

Re: Turbopack, the successor to Webpack

#185

Post by fragile_frogs »

VoidWhisperer wrote: post #181
fragile_frogs wrote: post #174

After years of configuring webpack for various projects I have finally decided to migrate all my projects to Parcel[1] manly because I got tired of creating and maintaining hundreds of lines of webpack.config.js files, I wanted something that just works. I am really happy with that decision. Parcel is plenty fast and is pretty much zero config, I can use it to build libraries[2] as well as applications[3] for the bro…

This has been a huge frustration of mine with webpack - you end up with relatively complicated configs and it sometimes feels like even if you copy and paste your config over, you end up still having to spend a ton of time fighting with webpack to actually get it to work

And when you try to upgrade just one plugin everything breaks and you have to upgrade everything.

Re: Turbopack, the successor to Webpack

#189

Post by tshaddox »

andsoitis wrote: post #82
tshaddox wrote: post #71

Earlier quoted context omitted.

I don’t think any of the current options are good enough that I would want the community to settle on one of them at this point at the expense of any innovation or experimentation.

We’ve been doing JavaScript development for how many years now? And still no bundling options that are good enough? Or at least one that can continue to evolve vs. creating a successor, etc.

For me the age of JavaScript isn't particularly important. I just don't think any one of the well-known options are good enough that I would want the community to throw a big portion of support behind it.

Re: Turbopack, the successor to Webpack

#190

Post by [deleted] »

simlevesque wrote: post #184
moron4hire wrote: post #175

Earlier quoted context omitted.

During hour to hour development, I just let Visual Studio tell me about the errors as they come up. On the rare occasions I don't already have the editor open before deploying, I have a shell script to kick off the right tsc invocation. Otherwise, bundling plus uploading to the server is just another shell script. Yes, a full type check from scratch is slow, but it doesn't come up that often.

To anyone who wants to do this: Let's say you have a tsconfig.json. Create a tsconfig-test.json like this: { "compilerOptions": { "noEmit": true, "skipLibCheck": true }, "extends": "./tsconfig.json", "include": ["./\*/*.ts", "./\*/*.d.ts"] } Add a script to your package.json (I use "test-types") ... "scripts": { "test-types": "tsc --project ./tsconfig-test.json", ... Then you can "yarn test-types" quickly. I use husk…

[deleted]
Post reply on HN