feat(vercel): ISR

[lilnasy]

Description (required)

• Adds configuration reference for a new option being introduced in the next minor version.
• Brief; detailed instructions would likely go on vercel docs instead.

Related issues & labels (optional)

• feat(vercel): ISR astro#9714
• [ci] release astro#10014

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
docs	✅ Ready (Inspect)	Visit Preview	Feb 7, 2024 1:18pm

1 Ignored Deployment

Name	Status	Preview	Updated (UTC)
docs-i18n	⬜️ Ignored (Inspect)		Feb 7, 2024 1:18pm

[VoxelMC]

From what I can see, it looks great! Nice work :)
LGTM

[lilnasy]

Thanks 😊

[sarah11918]

Quick q so I can prioritize, @lilnasy - I see you made the implementation PR into a draft last week. Would anything there that you might rework change this user-facing documentation, or is this content safe to review? Thanks!

[lilnasy]

It is safe to review. The reason for making it draft was resolved soon after.

[sarah11918]

This is going to need all that good stuff from the other PR's changeset!

[lilnasy]

This is going to need all that good stuff from the other PR's changeset!

From what I've seen with other frameworks, vercel documents ISR in more depth on their site. SvelteKit, for example. We have an opportunity to keep the changes here minimal and link to Astro on Vercel when it updates.

How much should we exercise this opportunity?

[sarah11918]

We need to document the configuration options! our stuff: expiration etc.

Unless, you're telling me those are all Vercel options that you can throw in your vercel({}) config. In which case, I'd want to reframe the changeset in the other PR to imply:

Use any of the config options here, for example to control cache invalidation...

rather than make it look like these are particular @astrojs/vercel config properties.

[lilnasy]

I am trying to figure out the criteria of what goes in the readme. Should VercelImageConfig have been documented as well?

[sarah11918]

My general rule is: anything that we built, literally anything you can configure or use that only we control, we should document.

If, for example (as I think was once the case with something in an adapter or middleware or something), we use/support someone else's entire options (we exactly mirror them), then a link to them would be sufficient.

I don't know what VercelImageConfig is, but if it is something we created, even if only in order to use their image service, then yes we should document it. BUT, for example, if all the config options are just mirrored from their service, that's where it's fine to link to them.

Does that help?

[lilnasy]

That helps, thanks!

I've documented VercelISRConfig.

I don't have the full context for VercelImageConfig but it is our config, and not present on docs. It can be a future PR, possibly by someone else.

[delucis]

Nice work @lilnasy! Left a couple of comments.

[sarah11918]

Some changes suggested to bring the readability up to that of the changeset from the other PR!

(No paragraphs inside code samples, plz! 😅 )

[lilnasy]

@sarah11918 Thanks, this is much clearer now!

[dreyfus92]

Readibility was improved by 1000%, thank you @lilnasy for tackling this and everyone else. LGTM 😁

[delucis]

Lovely work @lilnasy — I think this looks great 🙌

Tiny final suggestion to highlight the isr options in a couple of code blocks but basically LGTM 🚀

[sarah11918]

Thank you @lilnasy for your great work getting this into docs format! Ready for you to merge at will! 🫡