-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Allow adapters to customize headers for fetch requests #14543
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
base: main
Are you sure you want to change the base?
Conversation
…otection) Adds a new generic mechanism for adapters to inject headers into Astro's internal fetch calls. This enables features like Netlify's skew protection. Changes: - Add `runtimeConfig.internalFetchHeaders` to AstroAdapter interface - Create `astro:adapter-config/client` virtual module - Update Actions, View Transitions, Server Islands, and Prefetch to use adapter headers - Implement Netlify skew protection with DEPLOY_ID header - Generate `.netlify/v1/skew-protection.json` configuration file - Add comprehensive test fixture for skew protection
🦋 Changeset detectedLatest commit: 4e36b0d 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.
This PR is blocked because it contains a minor
changeset. A reviewer will merge this at the next release if approved.
packages/integrations/netlify/test/functions/skew-protection.test.js
Outdated
Show resolved
Hide resolved
packages/integrations/netlify/test/functions/skew-protection.test.js
Outdated
Show resolved
Hide resolved
- Add type declarations for astro:adapter-config/client virtual module - Add manifest property to SSRResult interface - Fix Object.entries type assertions in prefetch and router - Add explicit return type to Netlify adapter's internalFetchHeaders function
Follow existing pattern of extracting specific fields from manifest rather than passing the entire manifest object to SSRResult. This matches how other fields like base, trailingSlash, and serverIslandNameMap are handled.
CodSpeed Performance ReportMerging #14543 will not alter performanceComparing Summary
Footnotes |
- Remove incomplete test stubs for actions and view transitions - Remove unused manifestPath variable - Update prefetch comment to be less strict about dependencies
The test was checking ssr.mjs which is just a wrapper, but the actual serialized manifest is in the manifest_*.mjs file in the build directory.
This prevents timeouts in integration tests where client-side files importing the virtual module are processed during SSR.
commit: |
Is the virtual module meant to be exposed to users or is it purely internal? |
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.
The feature has a mixture of "client" and "runtime" concepts that seem to overlap, however we know that they are two different things.
I think we should normalise the nomenclature in our code and docs
/** | ||
* Runtime configuration that will be available to Astro's client-side code. | ||
*/ | ||
runtimeConfig?: { |
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.
We are already inside a configuration, so calling this Config
seems redundant.
Also, "runtime" and client-side code have different meanings to us, so I would look for a better name or a better description.
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.
Sure, what would you recommend? Below you recommended /runtime
for the virtual module, so I think runtime
here would be nice for symmetry. Sound 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.
Yeah, as long as we align the terms, I don't have strong opinions. But I think client
is a better fit, because runtime
is also code that runs on the server, which isn't the case.
Regardless, it's just a suggestion, as long as the docs and names are aligned, I'm good :)
import type { Plugin as VitePlugin } from 'vite'; | ||
import type { AstroSettings } from '../types/astro.js'; | ||
|
||
const VIRTUAL_CLIENT_ID = 'astro:adapter-config/client'; |
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.
The presence of /client
implies a possible /server
. However, it seems that's not the case, so maybe we should just remove it or call it /runtime
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 keeping /runtime
makes sense because it's just the runtimeConfig
object (pending a rename there), and perhaps in the future there would be a reason to expose other parts of the object.
It's more or less internal. I thought about making it exposed to the user so they could use it in their own |
Alright then the virtual module types should live in -"include": ["src"],
+"include": ["src", "dev-only.d.ts"], EDIT: you won't need to edit the tsconfig when #14538 is merged, soon |
Changes
runtimeConfig.internalFetchHeaders
to AstroAdapter interfaceastro:adapter-config/client
virtual module.netlify/v1/skew-protection.json
configuration fileTesting
Docs