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

Option to make prerender opt-out rather than opt-in #3792

Closed
madeleineostoja opened this issue Feb 9, 2022 · 0 comments · Fixed by #4192
Closed

Option to make prerender opt-out rather than opt-in #3792

madeleineostoja opened this issue Feb 9, 2022 · 0 comments · Fixed by #4192
Labels
feature / enhancement New feature or request

Comments

@madeleineostoja
Copy link

madeleineostoja commented Feb 9, 2022

Describe the problem

For large headless / static sites with a bit of api glue code, marking every single route with export const prerender = true is both unergonomic and unintuitive, considering other major serverless frameworks (eg: Next) automatically prerender all routes when possible.

A common pattern is to have all routes prerendered, and then an api/ route or similar for endpoints that would get translated to serverless functions you can request to.

Describe the proposed solution

There should be an option to make prerendering opt-out rather than opt-in for serverless adapters. Ideally an adapter like Vercel should attempt to prerender all routes by default, while keeping endpoints as serverless functions. That would be a fairly major breaking change, so making this a configuration option (false by default) would be a non-breaking and huge erganomic upgrade. Though I still think the default behaviour is odd, given kit's emphasis on performance and DX.

Alternatives considered

  1. Mark every route with export const prerender = true, unintuitive and prone to user-error
  2. Use adapter-static and manually deploy serverless functions for api routes / endpoints to provider of choice, largely negating the whole benefit of Sveltekit's deep serverless integration

Importance

nice to have

Additional Information

No response

@bluwy bluwy added the feature / enhancement New feature or request label Feb 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature / enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants