Skip to content
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

feat: middleware and virtual routes #10206

Merged
merged 10 commits into from
Mar 8, 2024

Conversation

lilnasy
Copy link
Contributor

@lilnasy lilnasy commented Feb 22, 2024

Changes

Testing

Docs

Mentions of 404.astro or spread routes needing to exist to run middleware should be removed.

Copy link

changeset-bot bot commented Feb 22, 2024

🦋 Changeset detected

Latest commit: a86386b

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 the pkg: astro Related to the core `astro` package (scope) label Feb 22, 2024
@lilnasy lilnasy force-pushed the feat/virtual-route-middleware branch 6 times, most recently from 9bce54c to 9f77710 Compare February 23, 2024 16:11
Comment on lines -34 to 38
it('does not return custom headers for invalid URLs', async () => {
it('returns custom headers in the default 404 response', async () => {
const result = await fixture.fetch('/bad-url');
assert.equal(result.status, 404);
assert.equal(Object.fromEntries(result.headers).hasOwnProperty('x-astro'), false);
assert.equal(Object.fromEntries(result.headers).hasOwnProperty('x-astro'), true);
});
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test checks that configured headers added in config.server.headers are NOT added in the 404 responses.

This behavior was limited to astro's default 404 page - if the user added a custom 404.astro, server.headers are still added.

The new behavior is that server.headers apply to all astro-generated responses - the distinction between astro's default 404 page and user's 404.astro is gone.

@matthewp
Copy link
Contributor

lgtm, still in draft though and missing a changeset.

@lilnasy lilnasy marked this pull request as ready for review February 23, 2024 22:17
@lilnasy lilnasy added the semver: minor Change triggers a `minor` release label Feb 23, 2024
@lilnasy
Copy link
Contributor Author

lilnasy commented Feb 23, 2024

Manually adding semver: minor because label workflow doesn't work on forks.

Copy link
Member

@sarah11918 sarah11918 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just setting a block for @lilnasy ! (I'm sure docs will want to look at this anyway) 💜

Copy link
Contributor

@OliverSpeir OliverSpeir left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

blocking per request


The astro middleware now runs when a matching page or endpoint is not found. Previously, a `pages/404.astro` or `pages/[...catch-all].astro` route had to match to allow middleware. This is now not necessary.

Note that some adapters may need to update to let Astro's SSR code handle the not-found case.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: "to update.." what? It feels like we should hint at something or maybe rephrase the sentence.

It would be great if the changelog actually explains what an adapter maintainer should update in order to "fix" this.

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 feel it adequately explains the change necessary.

Adapters may look at the list of routes given by astro to create their platform-specific routing file. And the platform may then run SSR code only for routes known to be on-demand rendered. The website would then fallback to a platform-designed 404 page. SST, vercel and cloudflare (in one routing strategy) work like this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel it adequately explains the change necessary.

I am sure it is, from your point of view. However, I fear that we don't provide enough explanation to people who have less context and knowledge than you. If you think this phrase is more than enough, we should remove it.

Adapters may look at the list of routes given by astro to create their platform-specific routing file. And the platform may then run SSR code only for routes known to be on-demand rendered. The website would then fallback to a platform-designed 404 page. SST, vercel and cloudflare (in one routing strategy) work like this.

You just replied with something that we can add to the changeset 😅

packages/astro/src/vite-plugin-astro-server/route.ts Outdated Show resolved Hide resolved
@ematipico
Copy link
Member

@lilnasy What about the documentation? The template is empty. We should have a PR for that, right?

@lilnasy
Copy link
Contributor Author

lilnasy commented Feb 26, 2024

Not necessarily. We don't explicitly document that middleware won't run in this case. We should also hold explicitly saying that will , until we know it works this way across adapters.

@ematipico
Copy link
Member

ematipico commented Feb 26, 2024

Not necessarily. We don't explicitly document that middleware won't run in this case.

Sorry for being pedantic, but I am a bit concerned by this kind of approach:

  1. Can you update the PR template and explain why docs don't need to be updated?
  2. Since this is a feature, we should actually document this new behaviour.

We should also hold explicitly saying that will , until we know it works this way across adapters.

And how do we plan to do that? The PR doesn't say anything about it.

@lilnasy
Copy link
Contributor Author

lilnasy commented Feb 26, 2024

updated the description

@ematipico ematipico added this to the 4.5 milestone Feb 26, 2024
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.

Thank you, Arsh, for addressing my concerns! Another minorready for the next release. Let's wait for docs :)

Copy link
Member

@sarah11918 sarah11918 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tiny suggestion from docs!

.changeset/brown-pets-clean.md Outdated Show resolved Hide resolved
@ematipico
Copy link
Member

We should update the documentation: https://docs.astro.build/en/guides/middleware/

We need to mention that now the middleware will run on 404 pages

@ematipico ematipico modified the milestones: 4.5.0, 4.6.0 Mar 8, 2024
@ematipico ematipico modified the milestones: 4.5.0, 4.6.0 Mar 8, 2024
@lilnasy lilnasy force-pushed the feat/virtual-route-middleware branch from 8b3378a to a86386b Compare March 8, 2024 16:24
@lilnasy lilnasy merged commit dc87214 into withastro:main Mar 8, 2024
13 checks passed
@lilnasy lilnasy deleted the feat/virtual-route-middleware branch March 8, 2024 16:39
@astrobot-houston astrobot-houston mentioned this pull request Mar 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pkg: astro Related to the core `astro` package (scope) semver: minor Change triggers a `minor` release
Projects
None yet
5 participants