refactor: provide 404.html without fs access

[hi-ogawa]

WIP
I think this can be minor cleanup. Interestingly dist/public/404.html might be the result of ssg-ing src/pages/404.tsx, but when non static mode, 404 is already handled by the router, so I don't think app.notFound handler is actually triggered?

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Updated (UTC)
waku	Ready	Preview	Sep 30, 2025 0:58am

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/wakujs/waku@1714

commit: c2eb018

[rmarscher]

"I don't think app.notFound handler is actually triggered" - it is triggered when requesting a page that is not matched by the router on the initial html request. https://waku-c3-test.martiandev.workers.dev/this-page-does-not-exist

[rmarscher]

notFountHtml typo. It should be notFoundHtml.

[hi-ogawa]

"I don't think app.notFound handler is actually triggered" - it is triggered when requesting a page that is not matched by the router on the initial html request.

To clarify, my statement "app.notFound handler is actually triggered" is for the case when src/pages/404.tsx exists, which I haven't fully verified. Is your example the result of public/404.html or src/pages/404.tsx?

[rmarscher]

"I don't think app.notFound handler is actually triggered" - it is triggered when requesting a page that is not matched by the router on the initial html request.

Is your example the result of public/404.html or src/pages/404.tsx?

Ah, yes. Sorry. You are right. I always forget about the src/pages/404.tsx pattern. I confirmed adding that always renders the 404.tsx and does not hit the app.notFound. Maybe we should add src/pages/404.tsx to the templates in the examples/0* folders.

It would be good to be able to render it during build to dist/assets/404.html. Most static hosting platforms can be configured to use a custom 404.html page. I confirmed that if define only static pages and layouts, I can delete the "main" and "assets.binding" keys from the wrangler.jsonc file and deploy a completely static site. Right now, it will use public/404.html if present. But that is still not using app.notFound then either, to your point.

[hi-ogawa]

Thanks for confirming. Yeah, so this means app.notFound solely exists for raw public/404.html convention, so we should be able to swap with virtual module with public/404.html?raw to bake that in.

It would be good to be able to render it during build to dist/assets/404.html. Most static hosting platforms can be configured to use a custom 404.html page.

Isn't it already working like this? if pages/404.tsx exists, Waku ssg will render it to dist/public/404.html. Then, for the static deploy adapter, we can configure it as general fallback html (which I'm not sure we do that now).

[rmarscher]

Isn't it already working like this? if pages/404.tsx exists, Waku ssg will render it to dist/public/404.html. Then, for the static deploy adapter, we can configure it as general fallback html (which I'm not sure we do that now).

I see. It will do that if public/404.html does not also exist. Right. 😄

[dai-shi]

when non static mode, 404 is already handled by the router, so I don't think app.notFound handler is actually triggered?

In Both static mode and non-static mode, app.notFound is not required for PRD. But, isn't it required for DEV?