new rule to cover `console_log_state`

[rallets]

Description

Hi, I'm wondering if there is a plan to include a rule to avoid console_log_state warnings at runtime

Ref: https://svelte.dev/docs/svelte/runtime-warnings#Client-warnings-console_log_state

Thank you

[baseballyama]

Since runes can also be defined in external files, it seems challenging to determine whether an argument passed to console.log is a rune.
Therefore, I feel it’s difficult to implement this as an ESLint rule. What do you think?

[rallets]

Thanks to taking a look to this. I didn't know it could have been so complex to detect runes. I thought the rune-detection was already part of the eslint plugin framework.
However I think it could cover a good number of cases if the console.log can detect runes defined in the same file (.svelte file or svelte.ts file).
And what about detecting if an argument is a proxied class?

A perfect rue doesn't exist maybe, but at least can help developers to detect early some common misuses, especially during migrations (like in my case). A later refactoring could be challenging and time consuming, as it requires rewriting part of the code.
I like eslint rules because they point to the docs and you learn always something new.

[baseballyama]

MEMO: By assigning a special branded type to Runes in the parser, it should be possible to determine whether a variable is a Rune. However, note that whether a proxy is used is decided at runtime. In other words, primitive Runes do not use proxies, so no console_log_state warning will be triggered.

That said, it might be possible to implement a rule that simply enforces $inspect on any Rune variable, without such fine-grained control.