feat: Add hono enhancer to cloudflare

[rmarscher]

Update unstable_honoEnhancer to accept an async function to support dynamic imports.

Update unstable_honoEnhancer to pass in the Hono app and the serveWaku Hono middleware handler.

Load waku config and invoke unstable_honoEnhancer in cloudflare build. If this looks good, we should all this too all of the deploy options.

With these changes, I am able to update my waku.config.ts to this in my Cloudflare Pages project:

import type { Hono, MiddlewareHandler } from "hono";
import type { Config, unstable_HonoEnhancer } from "waku/config";

const addApiRoutes = (app: Hono) => {
  app.get("/api/hello", (c) => {
    return c.json({ hello: "world" });
  });
  return app;
};

// @ts-expect-error TODO figure out the right way to cast types here
const wakuConfig: Config = {
  ...(import.meta.env && !import.meta.env.PROD
    ? {
        unstable_honoEnhancer: async (createApp) => {
          const devServer = (await import("./waku.cloudflare-dev-server")).cloudflareDevServer({
            // Optional config settings for the Cloudflare dev server (wrangler proxy)
            // https://developers.cloudflare.com/workers/wrangler/api/#parameters-1
            persist: {
              path: ".wrangler/state/v3",
            },
          });
          return (app: Hono) => {
            // @ts-ignore ignoring types here for now
            return createApp(addApiRoutes(app));
          }
        },
      }
    : {
      // @ts-ignore ignoring types here for now
      unstable_honoEnhancer: (createApp) => (app) => createApp(addApiRoutes(app)),
    }),
  middleware: () => {
    return [
      import("waku/middleware/dev-server"),
      import("waku/middleware/headers"),
      import("waku/middleware/ssr"),
      import("waku/middleware/rsc"),
    ];
  },
};

export default wakuConfig;

I use waku dev for local development and my API route is accessible.

I use NODE_ENV=production npm run build -- --with-cloudflare to build.

Unfortunately... when I deploy to cloudflare, I am getting a strange error when trying to access the API route:

Cannot access 'loadConfig' before initialization

for the line with const configPromise = loadEntries().then((entries) => entries.loadConfig());

It works without error when I run the build using npx wrangler pages dev so that is strange.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
waku	✅ Ready (Inspect)	Visit Preview	Sep 30, 2024 5:39am

[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.

[dai-shi]

Thanks.

[dai-shi]

I would like to avoid exporting type from this file. If you need it in the plugin, simply define it there.

[rmarscher]

Yes, that sounds good.

[dai-shi]

Promise<> is fine, but exposing serveWaku is too much. It doesn't look like a nice enhancer abstraction.

[dai-shi]

Another idea would be:

(createApp: (app: Hono) => Promise<Hono>) => (app: Hono) => Promise<Hono>

[dai-shi]

accept an async function to support dynamic imports.

Hm, on second thought, I wonder if promise is really necessary. Do you really need dynamic imports?

Can you try top-level await?

At this point, it's not convincing to change unstable_honoEnhancer.

[rmarscher]

Can you try top-level await?

Yes, I can try. It needs to import for the waku dev command and not import during build. I'm not sure if there is a better way to do that than using import.meta.env.PROD.

exposing serveWaku is too much. It doesn't look like a nice enhancer abstraction.

Exposing the built Hono middleware (serveWaku) is useful if the user doesn't want Waku to be the default route. I agree that it doesn't look as clean. Maybe we should leave it out until someone has a more compelling use case? I am fine with transforming the build output for my personal use cases.

I will make adjustments to this PR to remove the API changes.

I will also try to fix the error it throws when deployed to Cloudflare. I tried using top-level await there but the same error occurred.

[dai-shi]

useful if the user doesn't want Waku to be the default route.

We expose runner for such use cases. I don't think they would use unstable_honoEnhancer in such cases. But, maybe I miss some use cases.

I agree that it doesn't look as clean.

I would like it to be clean. 😄

Yes, I can try.

Let me know if it doesn't work. There might be other workarounds.