-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: dynamically import middleware #11550
refactor: dynamically import middleware #11550
Conversation
|
4fafe5b
to
020ed68
Compare
!preview dynamic-middleware |
Snapshots have been released for the following packages:
Publish Log
Build Log
|
This doesn't fix the issue fully yet, but I wound the following. If we could separate the helper functions https://discord.com/channels/830184174198718474/1228360509418504332/1266257419164450976 |
020ed68
to
75cbda7
Compare
!preview dynamic-middleware |
Snapshots have been released for the following packages:
Publish Log
Build Log
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we may need a changeset since it changes the build output, that could have an impact on adapters
c4eeaa2
to
21ca7ab
Compare
Changes
This PR refactors how we import the middleware file. This was a refactor I wanted to do regardless, but the Cloudflare issues put some pressure on it, so it's a good change regardless because it allows us to add more variables other than
onRequest
inside the middleware. Potential uses cases: errors, and more.Before, Astro always imported the
onRequest
method from the middleware file.Now, Astro imports the entire module, and then resolve the
onRequest
method from it.To achieve this, I used the
Pipeline
abstract class to define a shared method calledgetMiddleware()
, which is used inside theRenderContext
class.The
RenderContext::create
method is nowasync
, because during the creation of it, we need to resolve the middleware too.Testing
The existing tests should pass. I didn't add any changeset because this is an internal refactor, and the business logic didn't change.
Docs
It's an internal refactor, the functionality hasn't changed