[Feature]: support don't fallback to csr when ssr failed

[hardfist]

What problem does this feature solve?

sometime ssr failed means there's something wrong with the code, if we ignore the ssg failed and fallback to csr which may cause csr fail too, which happens in https://github.com/web-infra-dev/rspack/issues/7505

What does the proposed API look like?

add a option to disable ssg fallback

{
  fallback: false | 'csr' // false mean don't do fallback when ssg failed , 'csr' means fallback to csr when ssg failed
}

[zoolsher]

I believe I understand the context. The issue seems to be not with the fallback, but with what happens when SSG fails. You want the CI to break if the document's SSG fails, correct? Maybe we could provide a configuration option like { ssg: { strict: true } }.

[hardfist]

I discussed with @chenjiahan before and he thinks we may have different fallback strategy(csr or others), so fallback is more extensible than strict

[zoolsher]

Yes, but this seems more like a behavior of SSG rendering that determines whether it breaks the CI. And I think strict: true is more likely to break your CI pipeline than fallback: false.

I believe the title should be Break the Build When SSG Fails rather than Don't Fallback to CSR.

[chenjiahan]

Rspress v1 enables the CSR fallback by default, and we can not change the default behavior in non-major releases. The default behavior will be changed in Rspress v2.

So we plan to add the new fallback config first, and in Rspress v2, the default value of fallback will be false.

When users want to use the CSR fallback, they can add fallback: 'csr' to their config file. There can be more fallback types in the future.

[zoolsher]

fallback is not like something that break the build

[chenjiahan]

My bad, I didn't clearly explain the context of this option.

SSG will be strict by default in Rspress v2. And we will provide a config to allow users to opt-in to the current fallback behavior.

In this case, ssg.fallback is more semantic because it explicitly tells what the option does.

• ssg.fallback:

export default {
  ssg: {
    fallback: 'csr',
  }
};

• ssg.strict:

export default {
  ssg: {
    strict: false,
  }
};

[zoolsher]

SSG will be strict by default in Rspress v2.

by default or by force?

[chenjiahan]

by default. If users choose to use fallback, it is no longer strict.

[zoolsher]

Still, fallback: false doesn’t seem like a configuration that would break the build or throw an error.

If you insist on using the fallback field, I believe fallback: 'error' or fallback: 'strict' would be more appropriate than fallback: false.

[chenjiahan]

To be clear, are we talking about Rspress v1 or v2?

Rspress v1

If we are talking about Rspress v1, then I think adding the ssg.strict option is feasible, it is clearer than ssg.fallback: false.

However, we will have to remove it and add ssg.fallback in Rspress v2. This is because ssg.strict does not express the meaning of "fallback".

Rspress v2

Rspress v2 is now in design.

For v2:

• SSG errors will break the build by default, just like other SSG frameworks.
• Users do not need to configure something like fallback: false or strict: true.
• Users only need to configure fallback: 'csr' when they need the fallback behavior.

The SSG error is caused by SSG itself, not by fallback, so fallback: 'error' or fallback: 'strict' makes no sense in v2.

[zoolsher]

V1. I didn’t know anything about v2 before you mentioned it.

[chenjiahan]

Based on the above discussion, the final design is:

1. Add new ssg.strict config for Rspress v1, see https://github.com/web-infra-dev/rspress/pull/1325
2. Remove ssg.strict and add ssg.fallback in Rspress v2, see https://github.com/web-infra-dev/rspress/discussions/1105#discussioncomment-10324815