🐛 BUG: @cloudflare/vite-plugin ignore `run_worker_first`

[sammdec]

Which Cloudflare product(s) does this pertain to?

Vite Plugin

What versions are you using?

0.1.9 [@cloudflare/vite-plugin]

What operating system and version are you using?

Mac Sequoia 15.3.1

Please provide a link to a minimal reproduction

No response

Describe the Bug

Using the create cloudflare@latest --template react-swc-ts and adding the following assets config to the wrangler.jsonc

"assets": {
        "not_found_handling": "single-page-application",
	"binding": "ASSETS",
	"run_worker_first": true
	},

Then removing the following line from the worker

return Response.json({
      message: "Hello world",
    });

    // return env.ASSETS.fetch(request);

You will find it still continues to serve the index.html rather than returning "Hello world"

Please provide any relevant error logs

No response

[emily-shen]

Hi, run_worker_first has not been added to the vite plugin yet, which is still experimental. We should probably add some more helpful messaging around this, thanks for the report!

[marbemac]

Finding that this is actually important for oauth flows. E.g. for github login the callback might be something like http://localhost:3001/api/auth/callback/github, which is a top level navigation request - however the worker needs to handle this request, not the frontend client. Not sure how to get around the problem 🤔.

Unless there's a workaround, cf vite + spa won't work for any apps that rely on oauth for login.

[tmm]

I discovered the same thing when setting up OAuth (was very unintuitive). Ended up creating a separate worker to handle it.

[marbemac]

Yeah, probably what I am going to do as well (separate worker).

[lecstor]

I didn't want to have to figure out the separate worker so found another hack.
I tried to make it configurable be it looks like the config is vetted and the new prop I added wasn't available so hard-coded the path. I think this could be turned into a real solution though.

lecstor#1

yarn patch @cloudflare/vite-plugin

var ar = async (t14, e, n, r) => {
  return (
    (tr(n, Kt) &&
      t14.headers.get("Sec-Fetch-Mode") === "navigate"
      && !new URL(t14.url).pathname.startsWith("/auth/")) // <----- hackedy hack
      || (n = { ...n, not_found_handling: "none" }),
    !((await ir(t14, e, n, r)) instanceof ye)
  );
};

[whistlecube]

I didn't want to have to figure out the separate worker so found another hack. I tried to make it configurable be it looks like the config is vetted and the new prop I added wasn't available so hard-coded the path. I think this could be turned into a real solution though.

lecstor#1

yarn patch @cloudflare/vite-plugin

var ar = async (t14, e, n, r) => {
  return (
    (tr(n, Kt) &&
      t14.headers.get("Sec-Fetch-Mode") === "navigate"
      && !new URL(t14.url).pathname.startsWith("/auth/")) // <----- hackedy hack
      || (n = { ...n, not_found_handling: "none" }),
    !((await ir(t14, e, n, r)) instanceof ye)
  );
};

If this works, it wouldn't take much for this to be configurable in wrangler.json, right? We could list specific pathnames to ignore. @emily-shen quick fix perhaps?

[marbemac]

An option like that would be great! Just heads up that there's some relevant discussion over here as well -> #8798 (comment)

[whistlecube]

An option like that would be great! Just heads up that there's some relevant discussion over here as well -> #8798 (comment)

Thanks, good information over there. I'll use your client side redirect pattern for now, but I won't be happy about it lol

[marbemac]

Yeahhh, I'm not either tbh. But at least it works for now 🤷‍♂.