-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Add Incremental Static Regeneration support for the Netlify's on-demand builders #7975
Conversation
🦋 Changeset detectedLatest commit: e51d701 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
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.
locals
in an Astro component are read-only properties and you won't be able to set anything like this. The only place where you can write stuff in the locals is inside the middleware.
Ah, that is a very important limitation of this API! Should we use a |
@ematipico It works. Do you mean it should be read-only? |
There is no official word of this outside of Netlify's API reference, but most of on-demand builders' functionality has been brought into other functions. I found this out from a Netlify support thread, and the gist of it is, its use case has become niche: single cache store used globally - instead of per-region, as it is for normal and edge functions. This PR could still be merged for feature-completeness. I will be updating the Netlify part of the ISR guide to use |
Yes.
We don't use |
@ematipico Considering that serializability restrictions are relaxed, maybe a ---
Astro.locals.netlify.builders.setTtl(45)
---
<h1>Astro</h1> |
Yeah that's way better I'd say |
I would like a pointer for adding a no-op for dev. I see dev mode support was added in #7385, but the two tests added in it are for build. |
Yeah, the PR title is misleading (it was picked up from a third-party contributor). I am not sure how we can fix this case, with the code we have now. I think Astro should provide a safe way to retrieve the "adapter runtime", and if the adapter doesn't provide any runtime, it should be undefined. E.g. const runtime = Astro.locals.getAdapterRuntime();
if (runtime) {
runtime.setBuilderTtl(45)
} The downside is that these kinds of things are only visible when building the project and deploying it. |
Should I add a |
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.
Looks good!
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.
A couple of small changes, but after applying, good to go!
Co-authored-by: Elian ☕️ <[email protected]>
Co-authored-by: Elian ☕️ <[email protected]>
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.
Good to go!
Changes
Testing
Added a fixture
Docs
Added to the package README