Skip to content

Conversation

matthewp
Copy link
Contributor

@matthewp matthewp commented Oct 14, 2025

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

Testing

Docs

…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
Copy link

changeset-bot bot commented Oct 14, 2025

🦋 Changeset detected

Latest 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

@github-actions github-actions bot added pkg: integration Related to any renderer integration (scope) pkg: astro Related to the core `astro` package (scope) docs pr semver: minor Change triggers a `minor` release labels Oct 14, 2025
Copy link
Contributor

@github-actions github-actions bot left a 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.

- 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.
Copy link

codspeed-hq bot commented Oct 14, 2025

CodSpeed Performance Report

Merging #14543 will not alter performance

Comparing netlify-skew-protection (4e36b0d) with main (62ec8ea)1

Summary

✅ 6 untouched

Footnotes

  1. No successful run was found on main (6d68316) during the generation of this report, so 62ec8ea was used instead as the comparison base. There might be some changes unrelated to this pull request in this report.

- 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.
@matthewp matthewp added this to the v5.15.0 milestone Oct 14, 2025
@matthewp matthewp marked this pull request as ready for review October 14, 2025 20:56
@matthewp matthewp marked this pull request as draft October 14, 2025 20:56
@matthewp matthewp added the pr preview Apply this label to a PR to generate a preview release label Oct 14, 2025
@github-actions github-actions bot removed the pr preview Apply this label to a PR to generate a preview release label Oct 14, 2025
Copy link

pkg-pr-new bot commented Oct 14, 2025

npm i https://pkg.pr.new/astro@14543
npm i https://pkg.pr.new/@astrojs/netlify@14543

commit: 4e36b0d

@matthewp matthewp marked this pull request as ready for review October 14, 2025 21:44
@florian-lefebvre
Copy link
Member

Is the virtual module meant to be exposed to users or is it purely internal?

Copy link
Member

@ematipico ematipico left a 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?: {
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

@ematipico ematipico Oct 16, 2025

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';
Copy link
Member

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

Copy link
Contributor Author

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.

@matthewp matthewp self-assigned this Oct 15, 2025
@matthewp
Copy link
Contributor Author

matthewp commented Oct 15, 2025

@florian-lefebvre

Is the virtual module meant to be exposed to users or is it purely internal?

It's more or less internal. I thought about making it exposed to the user so they could use it in their own fetch calls but using the DEPLOY_ID in your own fetch calls is already easy enough.

@florian-lefebvre
Copy link
Member

florian-lefebvre commented Oct 16, 2025

Alright then the virtual module types should live in packages/astro/dev-only.d.ts instead, so they are not shipped to users. You'll also need to update astro's tsconfig:

-"include": ["src"],
+"include": ["src", "dev-only.d.ts"],

EDIT: you won't need to edit the tsconfig when #14538 is merged, soon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

docs pr pkg: astro Related to the core `astro` package (scope) pkg: integration Related to any renderer integration (scope) semver: minor Change triggers a `minor` release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants