Include a `worktop build` command

I’ve been going back on forth on this for a while… Basically, it’s a debate between:

1. Include a worktop CLI that builds a Worker for you
2. Offer a series of bundler plugins that you can import/attach to your existing toolkit

I suppose it’s possible to do both, but the array of plugins would be second-class in that scenario, especially since it’s (probably) unlikely that each integration could offer the same level of output refinement.

---

PROs

It’d be nice to have a ready-to-go build system for you, allowing (most) users to avoid the webpack that wrangler includes. This would solve low-hanging issues (eg #62, #73, #81). There’s already very little reason to use webpack anyway, but really, this is the only unmatched benefit to offering a build-in CLI solution. In other words, even with a worktop/webpack plugin, there’s still the "exports" and ESM resolving issue that I (as the plugin) can’t fix without risking other resolutions breaking.

That said, just to reiterate, any esbuild/swc/Rollup configuration works out of the box. Webpack is purposefully counter-compliant here. 👎

Either as a worktop CLI or as a series of plugins, I’m going to want to do AST transformations. For long before worktop’s first public release, I’ve had a PoC that compiles away the worktop Router in production. Even though the Router is already fast and lightweight, this removes all doubt and produces the most optimized form of the equivalent routing logic.

If I ship a CLI, it’s easier to defend including an entire @swc/core installation. It also means that worktop could lean into other compile-time optimizations/rewrites. Going the plugins route, I’d have to sheepishly include all of @swc/core anyway, which is kinda like embedding a bundler within your existing bundler, or rewrite all the same AST operations using the target system’s offerings –– i’ve explored this for another project… it’s not fun.

CONs

• Becomes an extra config file to learn/manage (can offer good defaults, but still)
• Having a worktop build sorta implies the existence/inevitably of a worktop dev command Can always attach miniflare/equivalent, but the expectation will be there and creates far more scope.
• Project scope grows significantly, especially trying to accomodate all existing user config
• Worktop is actually really easy/simple to build now. It doesn’t need any of the special sauce I’m talking about here.

---

Current Stance

Right now, I’m thinking that if I do this, it’d all take place under another package. That would mean that your package.json looks something like this:

{
  "scripts": {
    "build": "worktop build"
  },
  "dependencies": {
    "worktop": "latest"
  },
  "devDependencies": {
    "worktop-builder": "latest"
  }
}

This way, you only buy into all of the build-time optimizations if you decide to actually use/install worktop-builder (name tbd). If you don’t install and use the toolkit, then you use worktop as you/we already do today.

Two quick polls to (anonymously) weigh in on the points raised here. Thank you~! 🙇

Plugins vs CLI

Single vs Separate Packages

[lukeed]

Closing in favor of #95, which tracks the optimization work specifically. Already merged #94 which added the worktop.build package for a fast, simple-to-use bundler.

This will serve as an easy-yet-configurable solution for building a worktop Worker (or any Worker) instead of the default webpack nightmare that ships with wrangler by default.

[e0]

Initially it sounds like this would be nice for the dev experience but the point about the project scope seems like it could be a lot of work for relatively little gain. I don’t know much about these different build systems (webpack vs rollup vs esbuild) but I do know that I have never liked webpack.

After a quick look, it looks like esbuild and swc are really interesting alternatives. I would try to get one of these to work with my current project and see if there is a noticeable difference compared to webpack when it comes to re-building the project during development. I think for me, and maybe other developers, it would be ideal to have a starter template with worktop and esbuild/swc.

Looking back now, I guess I didn’t think of exploring other options since webpack is default for wrangler. Even with webpack though, there hasn’t been any real problems since the initial hiccup with #62 and I could entirely focus on developing without thinking about the framework.

I can’t really comment on the other technical points since I don’t understand them enough. Just wanted to provide some thoughts on the onboarding experience. If that (onboarding) is a main motivation for considering this issue I personally feel like some effort in documentation/examples would be enough.