v1 Roadmap

[dai-shi]

Here are tasks that I would like to finish before v1.

Previous Versions

-v0.14.0

• Server bundling Support server bundling with vite #21
• New API as middleware Expose as middleware #23
• RSC-only SSR (or opt-in SSR) ssr middleware #66
• Improve HTTP errors (404 instead of 500, especially with router) feat: support 404 for rsc #76
• Support interacting with server (req and res) feat: server context #86
• CSS Modules on server fix: partially for css modules #98 Support CSS Modules #105
• Server bundling issues not compatible with prisma #79

v0.15.0

• fix waku/router unexpected cached result #85 Ssr doesn't work if use getContext in entries.ts 's defineRouter/getComponent #104
• Revisit entries.ts API (requires to revisit waku/router) how to get current pathname in server component? #84
• Revisit mutate() api and maybe serve() api Redesign serve() and mutate() apis, and maybe getEntry too #119

v0.16.0

• waku/router [slug] support feat(router): slug support #133
• SWR build error in SWR 2.2.0 #96

v0.17.0

• Reconsider SSR (give up RSC-only SSR and go with full SSR) breaking: switch to full SSR from RSC-only SSR #147
• Node 20 fix: support node 20 #159
• Refactor rscPrefix config to rscPath rename rscPrefix to rscPath #160

v0.18.0

• Support running on the edge
• Vite 5 feat: use vite5 #207

v0.18.1

• css support feat: css support #240
• deploy support fix: vercel output #263 feat: output cloudflare #267 feat: output deno #271

v0.19.0

• Utilize hoistable elements breaking: no index html #289
• Renew waku/router API re-design waku/router #246
• Environment variables environment variables improvement #292
• Improve Vercel deployment
• Config file waku.config.ts support in cli.ts feat: waku/config #368
• Improve CLI and templates

v0.19.1

• fix issues with deployment
  fix: improve building for deployment #395
  fix: add already created index.html in the list #398
• fix style HMR
  fix: hmr plugin with async component (with ssr, dev only) #411
  DEV: loading indicator to mitigate FOUC #414

v0.19.2

• Dev improvement
  fix: FOUC #427
  CSS modules broken in DEV after #427 #439
  Cannot import commonjs module from server component #110
• More support for deployments
  feat: netlify deploy #422
  feat: output AWS Lambda handler #419
• router improvement
  router: do not refetch on popstate #424

v0.19.3

• ssr build / bundling wrong export from packages.json #448
• Support hot reload for server components #113
• Better Netlify support auto detect netlify build #465

v0.19.4

• feat: preserve module structure on server #493
• Support customizing 404 support custom 404 (static html only) #497
• build / image import broken #498
• useLocation not work Error: Missing Router #417
• feat: private dir #514
• Can not build with swr #418

v0.20.0

• support middleware and custom routes #513
• Enable SSR by default (no --with-ssr option)
• getContext from waku/server
• Conditional SSR
  feat: conditional ssr (minimal API only) #534
  Experimental support for disabling SSR for waku/router #569
• File-based router
  feat: fs-router #572
  fix: fs-router for non-Node envs #575
• Managed mode (no main.tsx and entries.tsx)
  feat: managed mode #580
• new waku/router apis
  feat(router): unstable_redirect #593
  feat(router): useRouter #613

v0.20.1

• Support omitting file extensions in import statements
  feat: support omitting file extensions in import statements #629
• Support .js and .jsx extensions
  feat: support js/jsx extensions (minimal api only) #633
  feat(router): support js/jsx extensions #636
• Support trailing slash with static sites (SSG)
  fix/router: handle trailing slash #637
• Bug fixes
  [BUG] Context Provider invalid value #631
  Fix broken 04_cssmodules example #651
  Suspense doesn't work in layout with css modules (DEV-only) #639
  ssr build / use client / broken global CSS import from package #452

v0.20.2

• Improvements
  SSG: support wildcards in static paths #666
  SSG: high volume performance #668
  feat(waku/router): prefetch on view (<Link />) #672
  fix: private dir hmr #675
  feat: expose internals #694
  SSG: partial builds #689
  fix(client): enable to render previous element in slot (experimental) #696
• Bug fixes
  fix(router): push state on redirect #673
  fix: non js assets path should add config.basePath to be relative to root path #697
  fix(waku/router): regex in file replacement to correctly handle all matches (fs-router) #678
  Avoid exposing configs that are not configurable #682
  fix: use both typescript and ecmascript prasers #687

v0.21.0

• Transform files on the server (DEV)
  feat: eliminate worker thread for react-server #762
  fix: avoid patching global webpack require #707
• Support importing server files directly from client files
  refactor waku/client (technically breaking) #708
  feat: use server action from client modules #714
• Support server actions in server components
  feat: server actions in server components #729
  fix: edge case when rsa depends on another rsa #785
• Router improvements
  breaking(router): string query #799
  feat: expose hash from useRouter #746
• Cloudflare Pages support
  feat: cloudflare pages adapter, alternate implementation #795
• Support customizing html attrs & head with SSR
  breaking: render full <html> instead of inside <body> #825
• DEV improvements
  fix(dev-server): initial modules recursive resolution and module loading in ssr #833

v0.21.1

• Minor improvements
  downgrade swc/core #848
  fix(build): do not remove index.html when buildConfig is empty #851
  [fix] File upload #850
  experimental: expose hono context #852

v0.21.2

• Improve build system (mostly internally, plugin system)
  feat(build): introduce buildData in platformObject #860
  feat: deploy plugins #866
• Bug fixes
  fix(dev): import local node_modules with SSR #864
  fix: cloudflare routing 404 #870

v0.21.3

• Improve build system (mostly internally, plugin system)
  fix(deploy): move isNodeCompatible to deploy plugins #876
  refactor(deploy): vercel serve and constants #877
  refactor(deploy): netlify serve #878
  refactor(deploy): cloudflare serve #879
  refactor(deploy): deno serve #880
  refactor(deploy): partykit serve #881
  refactor(deploy): aws-lambda serve #882
• Improve router
  feat: infer types for waku router #854
  feat: entries gen for fs router projects #886
• Misc
  feat(hono): enable context storage #891

v0.22.0

• Internal re-architecture (customizable entries with router)
• support for non-React API endpoints #329
• single waku.config.ts config file (no vite.config.ts)

v1-alpha

• Support monorepo setup
• Support progressive enhancement for forms
• Migrate to Vite Environment API
• More compatibilities with third-party libraries
  [Umbrella] Third-party library compatibility issues #423
• Explore code splittable styles (using React feature instead of Vite)

v1-beta

• Explore Jotai integration
• Explore support for third-party routers
  Integrate with TanStack Router #272

v1-final

• Wait for React 19

[Aslemammad]

How about actions? I was thinking about developing a plugin for vite a while ago, Since I think it's something similar to telefunc while developing this tool with Rom Brillout.

[dai-shi]

Actions (what I call "React Server Functions") are already implemented. I wouldn't say it's complete though.

[Aslemammad]

Nice!

[tom-sherman]

Anecdotally there seems to be a fairly large gap between waku's server actions and Next.js' implementation - I suppose this is expected because server actions are completely experimental in React right now.

IMO it makes sense to mark them as such (as an opt-in config option) before releasing v1.

[dai-shi]

I don't think our RSF (react server function) isn't that experimental, meaning it's the same level as react server component. I suppose Next's server action does more experimental things.

That said, I would like to revisit our approach anyway, which will require some feedbacks from collaborators/contributors/users.

In any case, unless we have an official doc or RFC from React, we wouldn't be able to finalize our API, which means v1 probably won't land until then.

[tom-sherman]

The problem with shipping server actions now (or before they're stable in React) is that the semantics are not specified yet. For example Next.js server actions are queued, it's impossible to execute them concurrently - not the case in Waku. There is also the integration with transitions, not sure if this is implemented in Waku.

IMO need to wait for a React RFC but only for server actions, there is already an RFC for server components and they're designated at stable by the React team.

This is why I think waku server actions behind a flag is the right way forward.

[dai-shi]

Yeah, if we would release v1 before the callserver RFC, we should hide it behind a flag. For now, just noting it's not finalized would be enough. But in that sense, everything isn't finalized.

[childrentime]

@dai-shi How about SSG? And change docs website to static files.

[dai-shi]

docs website is already static files.
we generate static files on build (SSG is a vague word, as people expect to generate HTML files.)

[dai-shi]

IMO it makes sense to mark them as such (as an opt-in config option) before releasing v1.

Having been working on #124, I'm getting more skeptical about the stability. (What is currently working may not work in the future.)
My gut feeling is that we should wait releasing v1 before React 18.3.0 or 19 is out.

[zouhangwithsweet]

So waku will not use react-server-dom-vite in the future?

[himself65]

So waku will not use react-server-dom-vite in the future?

I think it's up to upstream. currently react official repo only has webpack and turbopack support.

BTW, is react-server-dom-esm an alternative?

[dai-shi]

It depends on what react-server-dom-vite and react-server-dom-esm will be like.

Hope the esm one is published: facebook/react#27197

[ojj1123]

Integrate React Float

@dai-shi
What is React Float? What's the relation with no index.html?

[dai-shi]

Integrate React Float

@dai-shi What is React Float? What's the relation with no index.html?

I hope React docs will cover that soon. It will be called something like hoistable resource/elements.
It's technically not "integration". As #289 may tell, we no longer use index.html and add <title>...</title> in components, for example, which is possible because of hoistable elements.

[ojj1123]

I was wondering if you could explain where it is the explanation of defineEntries function in Docs or README! I couldn't find it since waku was released as v0.19.0. Is it deprecated?

[himself65]

I was wondering if you could explain where it is the explanation of defineEntries function in Docs or README! I couldn't find it since waku was released as v0.19.0. Is it deprecated?

No, that API is still available, but we don't have enough documents for the public APIs.

https://waku.gg/blog/introducing-waku

[ojj1123]

How about initializing git setting? (git init and then recomanded .gitignore, etc)
I think it's a bit low-priority but It seems like good to be at waku@v1.

[dai-shi]

#24 (comment)

@tom-sherman Do you know any updates?
I guess it's unlikely that the React docs specify such details.

[tylerlaws0n]

Explore Jotai integration

@dai-shi Is this still something that needs exploration?

If yes, what are some things that you'd be concerned about with using jotai + waku?

I suspect some exploration has been done already though, considering the waku.gg docs use example code with jotai as the state library.

[dai-shi]

I suspect some exploration has been done already though, considering the waku.gg docs use example code with jotai as the state library.

The example in docs is what's possible now. What I would like to explore is to use atoms on the server too (that is connected to the client behind the scenes.) So, it's a very tight integration (and one reason that I started developing my own framework.)

I have a goal but don't have the implementation idea yet. #11 is an old attempt.

Anyway, there are so many things to do before working on it.