Incremental build support

[kaushalyap]

AFAIK currently Astro need full rebuild for minor change, any plan to support incremental build where only rebuilding done for updated pages. Currently, Gatsby support incremental builds. This saves a lot of time for websites with large number of static pages.

[mitchellworks]

It seems like this would be very simple, to add to the cli and accept an arg. We hope this is prioritized so larger sites can migrate to Astro!

[steve-fenton-octopus]

I have a couple of sites with 1,000+ pages and I'm keen on something in this area to improve the developer-time experience. I use build + preview as I find it more reliable than the dev option. When I only change a markdown file (not a component that's used everywhere) a single build of that file would be amazing.

[grimalschi]

I agree. This is crucial for big projects with hundreds and thousands of pages.

[lilnasy]

I made a POC for incremental builds using deno (instead of node) for its storage backend. Here are the results when applied to astro -> typescript compiler. Admittedly, the astro compiler is already pretty fast but the same approach could be applied to other compilations.

To manage expectations, the work done by astro's built-in vite plugins (the part that runs when you see Building server and Building client) is largely not a good candidate for caching. However, caching can be applied to rendering in a static build and pre-rendered routes in a server build. This could save the time taken by querying a CMS, but patching fetch so that just those queries are cached maybe overall faster and simpler.

[omerman]

ISR would be amazing 🥹

[pateljoel]

@lilnasy As this is one of the most popular and most requested feature on the discussion roadmap alongside ISR #237, incremental builds is a must have for content heavy sites that astro is built for.

I have around 200,000 generated pages with Astro and I have to wait 10 minutes for EACH build which isn't ideal. At scale for around 400,000 I'll be waiting around 20 minutes and so on.

Assuming a user building their site with astro has already done their initial or first build, surely astro must cache this somewhere and diff / analyse changed files based on their content or hash then choose to only build content that has changed.

Even an analyse or diff ISR API would be helpful for developers that would like to customise their workflow of only updating changed files, perhaps only returning page paths ['/test1', '/test5'] that have changed and are ready to be rebuilt again.

[natemoo-re]

Great news! This proposal has been accepted and is moving on to Stage 2 of our process! 🎉

See Incremental Builds.

What does that mean?

The Astro maintainers and technical steering committee have agreed to explore official Astro support for this feature.

@natemoo-re has agreed to champion this proposal.

What happens now?

• Our team will begin exploring possible approaches for supporting incremental builds
• We will share progress updates on the accepted proposal as we progress
• The goal of Stage 2 is to determine the feasibility of a proposed feature. If it is feasible, the accepted proposal will graduate to an Stage 3: RFC + Development and implementation will begin

Where can we follow along?

This discussion will be closed. Please follow along on the accepted proposal. Don't hesitate to share additional feedback, use cases, or concerns on the accepted proposal.