Add a Cloudflare Pages build option (again)

[rmarscher]

We updated our --with-cloudflare build option from Cloudflare Workers to Cloudflare Pages and then back to Cloudflare Pages with Static Assets.

Related:

• How does the config file work? What's the difference between using `waku.config.ts` and/or `vite.config.ts`? #763
• feat: migrate cloudflare workers adapter to cloudflare pages #793
• feat: cloudflare pages adapter, alternate implementation #795
• Switch back to Cloudflare Workers #944
• Switch from Cloudflare Pages to Workers with Static Assets #989

I found that while Cloudflare Pages' advanced mode function and Cloudflare Workers are almost the same, it seems that Cloudflare Pages' advanced mode function runs after Cloudflare's edge cache while a Cloudflare Worker always runs before the cache. cloudflare/cloudflare-docs#20445

For sites that want to do SWR, it can be better to leverage Cloudflare's cache rules instead of using Cloudflare's cache API from within a worker.

[dai-shi]

If it's a long-term decision, we could separate two options: ---with-cloudflare-workers and --with-cloudflare-pages
Isn't the plan to integrate Workers and Pages in the future?

And, it depends on how much percentage of waku + cloudflare users need Pages.

Another option is to allow a user-defined deploy adapter.

[rmarscher]

Another option is to allow a user-defined deploy adapter

Could it be possible to pass a string in cli and then attempt to load that? Similar to the new string middleware config?

waku build --with-adapter './my-build-adapter'

That would work with a local ./my-build-adapter.ts in the root of my project and also open up for community waku build adapters hosted on npm.

[dai-shi]

Yeah, I like the custom build plugin approach.

Actually, it should already be possible with unstable_viteConfigs in waku.config.ts or vite.config.ts.
Would you give it a try and see if you face any problems?

[jkhaui]

@dai-shi I would like to attempt this if you have any guidance (@rmarscher too - not sure if much has changed in Waku since we last implemented the CF pages plugin).

I like the idea of giving users a --with-cloudflare-pages and --with-cloudflare-workers option. Even if we can just use the previous page plugin as a short-term solution while thinking about a long-term build system, that'd be great - I can't deploy my Waku project to CF anymore until there's pages support :(

I obviously don't have telemetry data related to Waku, but some other thoughts I have... CF Pages support is important because people look to Waku as a Next.js alternative in many ways:

• Vite instead of webpack
• Lightweight vs feature-heavy
• Ability to deploy to CF Pages instead of Vercel (I think we've had some evidence in discussions here that CF Pages seems like a popular deployment target for Waku).

I know it is technically possible to deploy Next.js to CF Pages with next-on-pages, but my understanding is that the size of Next.js' dependencies means you basically hit the max size restriction before even building your app.

[dai-shi]

@jkhaui Thanks for your interest.

As far as I understand, Cloudflare will support all pages features in workers. So, I would like to keep --with-cloudflare option simple.

Actually, it should already be possible with unstable_viteConfigs in waku.config.ts or vite.config.ts.

I'd highly recommend trying that ☝ , and if it goes well, we can write a guide in ./docs/guides/. Even further, create a plugin package and consider --with-adapter option.

[rmarscher]

I started looking at it and I think we probably need to export an unstable builder API with the lib/constants, lib/builder/constants, and emitPlatformData. Those are all used by most of the build plugins. I think they aren't currently exposed in package.json. unstable_getBuildOptions is also used often but that is already exported in waku/server.