Is partial mode build safe? and effective?

[hi-ogawa]

See https://github.com/wakujs/waku/pull/1789/files#r2532430895. I think this is very unsafe and probably we shouldn't remove it.

Okay, technically the explicit config is not there #1784, so it's entirely users risk. So my suggestion would be to remove such test case and remove this hack

waku/packages/waku/src/lib/vite-rsc/plugin.ts

Lines 550 to 557 in d40ab37

	// In partial mode, skip if the file already exists.
	if (
	fs.existsSync(destFile) &&
	// HACK: This feels a bit hacky
	destFile !== buildMetadataFile
	) {
	return;
	}

Let me find a simple example to create broken partial mode build.

[hi-ogawa]

I think prerequisite is that, there's no source code change, fully static (so no server reference), and it only changes staticPaths parameters. Actually the example exactly does that, so it might not be totally fine.

waku/e2e/fixtures/partial-build/src/pages/page/[title].tsx

Lines 7 to 10 in d40ab37

	export async function getConfig() {
	return {
	render: 'static',
	staticPaths: getEnv('PAGES')?.split(',') || [],

---

So, I think the question is whether new static elements mechanism allows skipping the same render from previous build.

[hi-ogawa]

So, I think the question is whether new static elements mechanism allows skipping the same render from previous build.

I think it doesn't anymore (though new static elements approach saves other part of redundant rendering such as shared layout).

For example, adding console.log('🔶', { title }) to here

waku/e2e/fixtures/partial-build/src/pages/page/[title].tsx

Lines 3 to 5 in d40ab37

	export default function Test({ title }: { title: string }) {
	return <div data-testid="title">{title}</div>;
	}

And repeated builds cannot reuse previous build's page component render:

$ PAGES=a pnpm -C e2e/fixtures/partial-build/ build
...
[ssg] processing static generation...
🔶 { title: 'a' }
✓ finished in 41ms

$ PAGES=a pnpm -C e2e/fixtures/partial-build/ build
...
[ssg] processing static generation...
🔶 { title: 'a' }
✓ finished in 40ms

[dai-shi]

Okay, technically the explicit config is not there #1784, so it's entirely users risk. So my suggestion would be to remove such test case and remove this hack

I think it's reasonable.

[dai-shi]

Linking to the original PR: #689

[hi-ogawa]

For partial mode, I think the abstraction we should aim for is something like entirely separate command to invoke SSG for specified pages with the existing "build" output. Conceptually this seems safe and more approachable (and I think Waku is made for that type of abstraction).

Anyways, now that RSC render needs to be revived from defineRouter:cachedElements, so this part needs to be solved as well though.

[dai-shi]

I think the abstraction we should aim for is something like entirely separate command to invoke SSG for specified pages

That's interesting. So, something like --only-build-route=/a?
(Yeah, it's better to store defineRouter:cachedElements in separate files in that case.)

[hi-ogawa]

I think the abstraction we should aim for is something like entirely separate command to invoke SSG for specified pages

That's interesting. So, something like --only-build-route=/a?

Something like that, or technically users could do that on their own with env var

waku/e2e/fixtures/partial-build/src/pages/page/[title].tsx

Line 10 in d40ab37

staticPaths: getEnv('PAGES')?.split(',') || [],

Since we assume users doesn't change source code, users should have getConfig to dynamically determine staticPaths (e.g. fetching slugs from CMS).

[dai-shi]

FYI, I don't prefer adding CLI options for waku/router which is separated from the core. So, the envvar might be preferable.