Incremental builds

[kg55kmr]

Describe the problem

I think it nice to have incremental builds similar to what Gatsby have https://support.gatsbyjs.com/hc/en-us/articles/360053099253-Gatsby-Builds-Full-Incremental-and-Cloud. It rebuilds only changed files. It can be big time saver for sites with a large number of pages.

Describe the proposed solution

Sveltekit rebuilds only changed files. As i understand, it must build dependency graph for all files in src/**.

Alternatives considered

No response

Importance

nice to have

Additional Information

No response

[dummdidumm]

Related (maybe reason to close this):

• A way to do this for adapter-static Incremental builds support for static adapter #2369 (comment)
• Using ISR instead Add incremental static regeneration #661

[kg55kmr]

@dummdidumm
It slightly different. For example, if I change component in src/lib/components and only routes that depends on that component
will rebuild.

[codepainting]

Incremental builds can address some real-world pain points when trying to create a unified user experiences.

The Problem — let’s assume a popular “startup” structure:

myunicorn.com        # landig page — marketing and design teams
myunicorn.com/app    # app to change the world — developers
myunicorn.com/blog   # blog — marketing team
myunicorn.com/docs   # docs — developers

All the apps have many common components — like header, nav, views etc., but also service-worker, site.webmanifest, static files and many more. So it is extremely beneficial for them to reside in a common codebase. If it's a monorepo (which helps a lot) is not that relevant for the main problem. Most importantly, code-reuse and optimal caching is key to providing a great user experience.

Typical Startup Workflow

Despite all the many common assets and components, all of these “sub”-apps serve a different purpose and have highly incompatible release schedules. E.g., the marketing team to do their best work, they cannot wait for the dev team to deploy the new landing page together with an upcoming app feature. They need their time-critical promo shipped “now”. On the other hand, the dev team has a point, when arguing that releasing a critical feature right before the weekend can turn into unexpected trouble and might be a bit irresponsible despite all the “release early, release often” hype. Yes, feature branches help, but many who have worked in a startup or portal newsroom know, that reality is often different from best-case scenarios. These are real-world day-to-day problems.

Solutions Evaluated

Subdomains — too many disadvantages

Operating subdomains for the individual apps is not a great option, and there is a common trend against subdomains for valid reasons. SEO is just one of them. User experience and brand recognition is another. Even more importantly, there is no way of providing a great user experience for installed PWAs with multi-origin apps because of security reasons and the same-origin policy.
Same-origin policy at MDN: (https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy).
An insightful article on this topic at Web.dev: https://web.dev/multi-origin-pwas/

Redirecting subdomains to folders — also many disadvantages

It is possible (with some really hacky workarounds on some platforms) to “redirect/rewrite” responses from requests from subdomains and “pretend” as if they were coming from a subfolder. But this is quite tricky to set up, works only for GET requests, and has the disadvantage, that — still being completely separate apps behind the scenes — common assets are not cached for all apps, but individually. Conceptually, this also feels as the wrong and wasteful way to do.

Proposed Solution

The proposed solution would be to allow to define portions of the app for incremental rebuilds and allow partial uploads to platforms.

Just to show a line of thinking:

pnpm build --scope /blog

Which would build just the blog “sub”-app.

Automated CI/CD workflows would need to be well-supported, since they would most likely be triggered by the individual teams from within their platforms.

More granular control (per page basis like suggested in earlier comments) would be — from my viewpoint — an extension of this scoping concept, ideally suited for hotfixes and (sub)-apps with many pages, like stated.

Considerations

This concept might not be doable solely on the framework level and would probably need cooperation (platform support) from providers. Platforms would need to support partial uploads, which for the ones I am aware of, is not the case as of now. Every release means, practically, that everything is uploaded as new.

Platform specific adapters could expose the proposed scoping functionality and the ones supporting incremental builds would allow the framework to proceed with an incremental build while for others an informational error would be thrown.

Other Options Considered

A concept of “sub”-apps could provide the same scoping capability, while going even further and allowing the creation of completely separated apps, to be run at different routes (folders). These apps would be managed from a semi-separate codebase (e.g., a different, but connected workspace in a monorepo with access to common components). For maximum flexibility, these apps could also be provided by a contractor, who only has access to the app’s codebase and the common components. E.g., for a newsroom this would allow creating an individual (separate) PWA for a sports event run from a route like newsportal.com/sports-event without touching any of the other codebase, but still providing a common newsportal-branded UI-shell.