[breaking] Analysing code during build

[Rich-Harris]

PR: #7762

When you build your app, SvelteKit will analyse your entry points (+page.js, +page.server.js and +server.js) during prerendering, so that it can know which ones can be excluded from your server (i.e. there's no point including code to render your /about page on-demand if that page is already prerendered).

In future, it's quite likely that we'll want to add more information to those entry points. For example, we might want some pages to be rendered at the edge, while other pages are rendered in a specific region near your database; some endpoints might run in a worker-type environment, whereas others need to run in a Lambda so that they can use native Node modules. Today, these things are only configurable on an app-wide level, which only goes so far.

An example of how this could look:

// src/routes/+page.server.js
export const config = {
  region: 'edge'
};

export function load() {...}

The best way to express that configuration is almost certainly as an exported variable that's read during build (rather than adding JSON configuration or doing some funky static analysis stuff — we want to be able to use environment variables and imports and type safety and everything else). That means doing the same thing for config as we currently do for prerender — loading each entry point and reading its exports. The config would then be passed to adapters so that they can validate it and prep the deployment accordingly.

(It could also be used to — for example — ensure that you weren't importing Node modules into places where they can't be used.)

Here's the wrinkle: to do this, we need to run your code as soon as we've built it. We don't need to actually render anything (unless it's marked as prerenderable), but we do need to import and evaluate your entry points, which could (for example) result in db connections being set up.

Today, you can disable that with config.kit.prerender.enabled = false. But if we're leaning more in this direction, we would probably need to get rid of that option.

We should also change the name of the import:

-import { prerendering } from '$app/environment';
+import { building } from '$app/environment';

In theory, it should be possible to disable any problematic code with an if (!building) {...} block. But in the past, there's been some confusion around this. So I'd love to get a better sense from people as to whether this is something we can realistically do, or if there are problems we're not foreseeing?

[dummdidumm]

I guess most people probably set up their DB connections as part of hooks.server.js, so it's maybe a good idea to setup something like a start hook which gives these things a more obvious place. That hook would not be called during building. Then again, what would such a hook mean in the context of "some things run on the edge, some somewhere else" etc - would setup code run for all of them? How would you know in which context you are setting up the DB? Is it necessary to know that?

[Rich-Harris]

I guess most people probably set up their DB connections as part of hooks.server.js, so it's maybe a good idea to setup something like a start hook which gives these things a more obvious place.

Possibly, though I think it'd be worth seeing how far we can get without it — we can add it later if necessary.

what would such a hook mean in the context of "some things run on the edge, some somewhere else" etc

Yeah, this is an interesting question, and a good reason to prefer this pattern...

// src/routes/some-endpoint/+server.js
import { db } from '$lib/server/db-that-requires-node.js';

export const config = {
  runtime: 'node'
};

export async function load() {
  return db.get('whatever');
}

// src/lib/server/db-that-requires-node.js
import { createClient } from 'some-db';
import { DB_CONNECTION_STRING } from '$env/static/private';

export const db = await createClient(DB_CONNECTION_STRING);

...over a global setup hook, since that code wouldn't be imported for routes that didn't use the Node-only db.

[jerrygreen]

I'm from the last ones who argued about this issue, and it kinda seems it isn't relevant to me anymore.

Because of what I currently do now is this:

1. When I want prerender, I don't have to do anything, as in the most recent Svelte/SvelteKit versions this is default behavior.
   Just write normal Svelte html: works like a charm 👌
2. When I don't want prerender, I currently have some variable set inside onMount + {#if flag} in html.
   Not sure if it's intended «how-to», as there are those +page.server.js and +server.js etc, but seemed to me most obvious when I wanted to get rid of prerender. At least it's obvious for people like me, who come from React. And it just works.

I.e. I'm completely OK if you remove option config.kit.prerender.enabled = false.

This will definitely break some other people's apps who still try to make old-fashioned SPA instead of MPA, when they update, - but you can probably show them a clean error that this setting is not supported anymore, and give link why.

Guys, just don't do SPA, heck... Make MPA. Preferably, with Svelte 👍

[coryvirok]

Exporting config from code vs making another filenaming convention is a good idea. I'd argue all configuration should be exported this way vs any filenaming convention in order to provide an escape hatch for folks who have a hard time swallowing the conventions.

One of the main arguments that was used against doing this to identify which layout should be used for a page, (vs using a filename convention) was that you'd have to parse and execute the page in order to determine the layout. Maintainers didn't want to use a complex regex to identify pages. So they put it in the filename. Seems like this pattern is resurfacing with config per page.

If parsing and executing pages at build time is no longer a dealbreaker, and you implement config for pages as an export, you may get closer to being able to abstract the routing config away from filenames.

Hope that's helpful

[Rich-Harris]

Layouts are a bit of a special case here, because you need to import the leaf in order to know which parent layout applies (and then import that to know which its parent is, until you hit the root). You could have multiple build phases, so that after the first build we figure out the layout hierarchy then kick off a second build that bakes it in to the route manifest to allow more efficient loading, but the server and client runtimes still need to be able to accommodate both kinds (parallel and reverse sequential loading). It adds a lot of complexity for (IMHO) questionable gain.

[dummdidumm]

Wouldn't we need to have two builds anyway? In order to figure out what runs where, we would need to do a build/run to get the configuration. With that information we then would do X more builds, one per environment where this runs on (a build with only the prerendered files for the CDN, another for edge function SSR, etc).

[benmccann]

I was wondering at first if this might break "Truer SPA Mode" (#1650), but since the options would all be in .js files and not .svelte files I think it should be relatively safe.

[cdcarson]

This is a way bad idea. If SvelteKit can't analyze a piece of code without running it, that's a sure sign that it has overstepped its remit.

[cdcarson]

Following the Next docs cited above, it seems one would export a constant...

// +page.server.js
export const runtime = 'nodejs'; 
export const load = (event) => {
  return { wontWorkUnlessItsNodeJS: __dirname };
);

...to indicate that load needs a particular runtime. So the runtime is determined statically, not from executing load against a set of runtimes to see which one, if any, happens to work.

As far as I can tell from the Next docs, all the other config, cacheing, etc., is similarly analyzable, statically, before the build step.

What they leave out (again AFAICT) is the notion of "running the function afterward, just in case it returns something different based on the deployment's environment." Sorry if I'm garbling what is intended, but I really don't get what the use case would be.

The thing is we're already executing all of your code

This is not currently true for server functions. I can build my project without a database connection. This would fail if SvelteKit were running them.

[Rich-Harris]

This is not currently true for server functions

It is! If you add a foo/[bar]/+server.js file (the dynamic [bar] bit is to guarantee that the crawler won't treat it as an entry point, just to demonstrate what I'm saying) that contains something like this...

console.log('hello')
export function GET() {
  console.log('rendering');
  return new Response('ok');
}

...then you'll see the hello message pop up at build time (as long as you don't have config.kit.prerender.enabled === false). You just won't see rendering.

I talked to the Next team to get a clearer picture of what they're doing, and it turns out that they are doing build-time evaluation, but they also do static analysis to check that you're exporting constants, to give them the option of only doing static analysis in future.

But they also told me that they've been doing build-time evaluation for a very long time — necessary for things like getStaticPaths and getStaticProps, and in Next 13 for generateStaticParams — and it hasn't been a problem. Which mirrors our experience of prerendering.

[cdcarson]

Well, I'll be. You're right. The reason build works for me without a db connection is that I get it always from within the scope of a function (which isn't called as of now.)

I'd prefer those functions to remain uncalled (traffic spike --> new instance(s) --> not the best time for extraneous db/api/xyz load) but I guess that's workaround-able -- your if (!building) from above or something else.

Thanks for the explanations, as always.

[dummdidumm]

To be clear if you have things inside load/handle right now, they wouldn't be called either with this change. The "we have to evaluate/run your code" relates to importing your code to read a potential config object - load etc wouldn't be called.

[Rich-Harris]

Ah, that's an interesting pattern. If you're doing this sort of thing...

import { createClient } from 'some-db';
import { DB_CONNECTION_STRING } from '$env/static/private';

export const db = await createClient(DB_CONNECTION_STRING);

// src/routes/my-route/+page.server.js
import { db } from '$lib/server/db';

export async function load({ params }) {
  const thing = await db.getThing(params.whatever);
}

...then in theory you shouldn't be creating those extraneous connections anyway, as the connection would be created as a side-effect of SvelteKit importing the code to render /my-route. But if the code was all bundled together with esbuild or whatever then it could be created eagerly. Will need to play around with that and see if there are any best practices we need to document.

[ByteAtATime]

One idea might be to name it in the file, such as +page.edge.svelte as opposed to +page.prerender.svelte.

[Rich-Harris]

Much too restrictive — where would you add configuration about e.g. how much memory should be allocated to a specific lambda?

[GlistenSTAR]

Much too restrictive — where would you add configuration about e.g. how much memory should be allocated to a specific lambda?

Yes, I think so.

[alexbjorlig]

For example, we might want some pages to be rendered at the edge, while other pages are rendered in a specific region near your database; some endpoints might run in a worker-type environment, whereas others need to run in a Lambda so that they can use native Node modules

I love how ambitious you are on behalf of Sveltekit. It would be a killer feature in the not-so-distant future running edge functions, communicating with some edge-deployed database ✨

What about the complexity of different providers? What if Vercel workers are different than Cloudflare workers? Would be 10/10 awesome if I hypothetically changed the adapter from Vercel to Cloudflare workers, and then got a warning/error from the adapter saying something like Cloudflare edge runtime does not support this feature XYZ.

[Rich-Harris]

Portability is the goal, yes — ideally there'll be certain conventions, e.g. region: 'edge' should work on both Vercel and Netlify. It would be up to individual adapters to look at the config and decide whether it needs to warn or throw an error that says 'you said config.color === 'fuchsia' and I don't know what to do with that'. But we haven't begun to design this feature yet, this discussion is just about reserving the space to do so

[alexbjorlig]

Will be amazing to accomplish this. If we could SSR some pages on the edge, it would be possible to for example render a button that was either showing "sign up"/"go to app" on our marketing pages (something that we today do with onMount - and hence won't work without js).

Would it somehow be possible that the build process could actually fail if you used a node library that was not supported on the edge? (possibly combined with warnings directly in VS Code)?

I know you are probably super busy Rich, but I'm trying to run playwright in parallel with our Sveltekit project and hit some errors. I think it's related to this issue (occurs when trying to start Sveltekit with the vite dev server directly in node) - but I might be wrong.

[alexbjorlig]

It would also be extremely nice if we could configure some edge functions to only run in specific regions.

At Vercel you currently have 3 options for edge functions;

1. Globally
2. Specific location
3. List of locations (enterprise)

Would be so cool, if this could somehow be expressed in the configuration. But again, this will probably differ from provider to provider, so maybe it should live in a global config file - or individual adapters could maybe extend the page-configuration objects?

[Tal500]

Today, you can disable that with config.kit.prerender.enabled = false. But if we're leaning more in this direction, we would probably need to get rid of that option.

For my testing, I like to build some projects locally with prerendering disabled (for debugging prerendering issues and also for faster build time). Therefore, removing the options to (temporary) disable prerendering is not preferable for me, and I believe also for other people.

I do agree that this configuration in svelte.config.js is problematic. As a compromise, maybe except some environment variable to disable prerendering or such?