Moving framework middlewares to separate packages

[tony-sull]

This is a very cool project, excellent work! Having lower-level control over the authentication and authorization flow without working around a built-in UI layer is extremely helpful as a project scales past the most basic OAuth flow!

---

I'm torn on this idea myself - each middleware is so small it feels like a shame to spin up totally separate packages for them!

Why?

I was testing out the Astro middleware recently and ran into a typing error, specifically related to a mismatch in Astro's built-in AstroCookies type compared to the cookies type used in Lucia. I don't have it in front of me at the moment, but it was effectively a mismatch where one was expecting string | undefined and the other expected null as well

A separate @lucia-auth/astro package might simplify the typings a bit since it could depend on the astro package and use Astro's APIContext type directly. Lucia's cookies type is used by all supported frameworks and may run into mismatches where cookies APIs work slightly differently in the various frameworks.

Alternatives

There may very well be a more simple solution that I haven't tested out yet. Would including astro as an optional peer dependency allow the current middleware to use the framework-specific type?

[pilcrowonpaper]

I don't have it in front of me at the moment, but it was effectively a mismatch where one was expecting string | undefined and the other expected null as well

Can you open an issue for that? That shouldn't be happening.

A separate @lucia-auth/astro package might simplify the typings a bit since it could depend on the astro package and use Astro's APIContext type directly.

There was an @lucia-auth/astro but it didn't provide much value. Using APIContext directly won't work as well since it changes ever so slightly with every minor change.