How does the config file work? What's the difference between using waku.config.ts and/or vite.config.ts?

[jkhaui]

Hey,

I really like the path Waku is pursuing as a lightweight React framework compatible with Vite, RSC, runtime/deployment agnostic, etc.

I have a question regarding the intended project setup. From my browsing of issues & discussions in this repo, my understanding is the goal is to shield end-users from having to setup a config file. However, for "power users", you can add a vite config file.

Just then I tried adding middleware to my starter project and noticed there's also the option to add a waku.config.ts file. Naturally this is where I'm confused and wondering, how does this work with a Vite config? Am I meant to use both together, or are they incompatible?

Thanks for clarifying!

[dai-shi]

Hey, thanks for trying out and asking.

The general goal is to have a good default and avoid "normal" users to require config files.
But, as it turns out, config files are required for "not-so-advanced" users for now.

We have two files waku.config.ts and vite.config.ts. Currently they are for different purposes, waku specific or not.
But, we will consider having a single config file to support both.

Until then, you should use both of config files up on your requirement.

[dai-shi]

If it looks like it's the best practice for the future, I think we should change the current CFW deploy script to CFP one. I didn't know which was the right choice and CFW seemed low-level, so that was it.

[jkhaui]

Yeah, it can be quite confusing. But at least Hono does most of the heavy lifting for us!

I guess I will start working on this following the pattern used by the other adapters: https://github.com/dai-shi/waku/tree/main/packages/waku/src/lib/builder. I'll call it cloudflare-pages to differentiate from the current cloudflare workers files

This is probably a good time to mention that I think adapters and having a modular adapter system is essential for Waku to gain traction and be well-recognised as an alternative React meta-framework to Next, Remix, Redwood, etc.

We could start thinking about how this can be architected such that the current lib builder files are extracted into separate packages e.g. npm i @waku/vercel. This could help make the core Waku package lighter to install in a dev environment, what do you think?

[dai-shi]

I think adapters and having a modular adapter system is essential

Yes, that's exactly what I thought, mainly because we can't maintain all adapters in this repo.
That should be definitely addressed before v1.

[jkhaui]

Btw, I had challenges getting my dev environment running on a Windows machine. But looks like I finally got it working by adding the cross-env package and creating a custom node script to properly handle loading of the NAME environment variable

Should I open a PR for this? I don't have a Mac/Linux so can't verify if it's broken anything on these OS

[dai-shi]

@himself65 should be using Windows. How does it work?

I'm against to adding cross-env. I think pnpm has a capability for posix compatibility?

[jkhaui]

Hey I'm revisiting this to try and get cloudflare pages integration working

I could definitely do with some pointers on how to get started as it's quite intimidating to learn the build process.

My understanding so far:

1. I should use Hono's Vite CF Pages plugin
2. I should find some way to add the plugin to Waku's internal build process, most likely somewhere in this file

Does this seem correct so far? Any other suggestions you might have? Cheers!

[dai-shi]

I should use Hono's Vite CF Pages plugin

I'm not sure. What does it do?

add the plugin to Waku's internal build process

That might be very tricky (and not stable) unless other plugins have done it.

[jkhaui]

I'm not sure. What does it do?

That might be very tricky (and not stable) unless other plugins have done it.

Thanks for getting back 🙏

Cloudflare Pages is the recommended way to host web apps on CF now, seems like worker sites are deprecated. CF pages gives a much better platform to build off with features like auto-deployments from git, accessing CF edge middleware, etc.

Seeing as Waku uses Hono internally I figured hono's CF pages plugin is what I should try to use.

Surprisingly I've actually made progress, I got a dev workflow going where I can inspect each step of the build process

I'll try figure out as much of this myself before asking for help. So far I've created with-cloudflare-pages as a new deployment type. Not sure if my understanding of the build process is correct, but here's how I'm approaching initial implementation:

1. Let waku handle most of the initial build steps (e.g. bundling the client, ssr, & rsc assets)
2. Add a new function like emitCloudflarePagesOutput where I'll call viteBuild and pass in the hono cf pages plugin with the entry file from dist specified

And I'm still trying to work out how serve-cloudflare-pages should fit into this. I also don't know if I'm approaching this completely wrong, I might just be duplicating the build process