Thank you for posting the rule suggestion.
That rule is sounds good to me! However, it may be useful for more users to extend the rule further and make it a check rule similar to @typescript-eslint/restrict-template-expressions. What do you think?
https://typescript-eslint.io/rules/restrict-template-expressions/

Svelte 5 solved this issue.
https://svelte-5-preview.vercel.app/#H4sIAAAAAAAAE0WKzQoCIRDHX0X-Z6G7bUHPkR1CRxjYnRHHDUJ89_DU8fcxUHgnQ3gOyPsgBDxqhUf_1gX2ob0TPEzPlpbZLDWu_R4l9qRi3RVVd3OnZCoslK9Rtst_kpXZXMQoqjMCHodmLkwZobeT5mv-AJMTcguHAAAA

So should we implement rules for Svelte 4 now that Svelte 5 is RC?

I think what users need to do is migrating the app to Svelte 5 instead of adding the rule.

I didn't know that 😅 I can’t wait for the GA of Svelte v5!!!

Thanks for pointing out this evolution is Svelte 5.

I am concerned whether this is a better solution. Usually, when I had undefined or null rendered, I had to add a #if block not only around the variable displayed but around some dom elements (<p>name: {name}</p>).

Maybe it's still necessary to have this rule but as a warning and not an error?

Yeah, I think the priority has been lowered, but someone might want to make sure it's explicitly a string.

This should never be allowed. The Svelte 5 solution in my opinion is actually a footgun. We need a way very much like @typescript-eslint/restrict-template-expressions to disallow non-string or non-primitive values from being serialised into [object Object] as this is a major potential bug surface for apps