New rule: `no undefined variable in the DOM`

[Ennoriel]

Motivation

When using a variable (say a props) that can be null or undefined directly in the DOM, it will be rendered as a string "null" or "undefined". Hence, it is probablly never going to be a good thing to use a possibly null or undefined variable directly in the DOM.

Description

The rule would highlight any variable or expression used in the DOM that resolves to a type involving a union type to null or undefined.

Examples

<script lang="ts">
  export let prop: string | undefined = undefined;

  const frameworks = ["svelte", "react"]
</script>

<!-- ✓ GOOD -->
{#if prop}
  {prop}
{/if}

<!-- ✗ BAD -->
{prop}
{frameworks.find(framework => framework === prop)}

Additional comments

No response

[ota-meshi]

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/

[baseballyama]

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?

[baseballyama]

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

[ota-meshi]

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

[Ennoriel]

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?

[ota-meshi]

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

[AlbertMarashi]

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

[marekdedic]

Drive-by comment: Maybe there should be a more general rule that requires everything in a mustache expression to be a string? (Or possibly number could also be allowed, maybe gated with a configuration flag?)

[ota-meshi]

If we refer to @typescript-eslint/restrict-template-expressions, it might be good to have the following options:

    /** Whether to allow `any` typed values in template expressions. */
    allowAny?: boolean;
    /** Whether to allow `array` typed values in template expressions. */
    allowArray?: boolean;
    /** Whether to allow `boolean` typed values in template expressions. */
    allowBoolean?: boolean;
    /** Whether to allow `never` typed values in template expressions. */
    allowNever?: boolean;
    /** Whether to allow `nullish` typed values in template expressions. */
    allowNullish?: boolean;
    /** Whether to allow `number` typed values in template expressions. */
    allowNumber?: boolean;
    /** Whether to allow `regexp` typed values in template expressions. */
    allowRegExp?: boolean;

[marekdedic]

@ota-meshi Yeah, something like that would be really nice - string is allowed by default, everything else gated by an option :)