Expected a # character immediately following the opening bracket - svelte(block_unexpected_character)

[Blue-Nomad]

Describe the bug

In Svelte 4 I was able to do:

{ #if expression }
    ...
{ :else if expression }
    ...
{ :else }
    ...
{ /if }

{ @html '<div></div>' }

Now in Svelte 5 that's an error. The following works but looks inconsistent:

{#if expression }
    ...
{:else if expression }
    ...
{ :else }
    ...
{ /if }

Reproduction

https://svelte-5-preview.vercel.app/#H4sIAAAAAAAAE0XNzQqDMBAE4FcZtgcvgvTnFETa59AepG7oQkyCiUKRvHtZKvS0M98cdicrjhOZfic_zkyGHjFSTfkTtaSNXWaqKYV1eam0PzIhZgk-YVk9JzTd4Ae_4yQWeVkZZfAAcFY07BJDLOyo4Zgu_-mQq0ojVrvG-zvPDlU7ydbd2kZPhUI1zWESKzyR0V_lWb7XAM1xxwAAAA==

It works when you disable Runes Mode.

Logs

No response

System Info

System:
    OS: macOS 14.7
    CPU: (12) x64 Intel(R) Core(TM) i7-8700B CPU @ 3.20GHz
    Memory: 29.51 MB / 8.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.17.0 - ~/.volta/tools/image/node/20.17.0/bin/node
    npm: 10.8.2 - ~/.volta/tools/image/node/20.17.0/bin/npm
  Browsers:
    Chrome: 129.0.6668.60
    Edge: 129.0.2792.65
    Safari: 18.0
  npmPackages:
    svelte: ^5.0.0-next.260 => 5.0.0-next.260

Severity

annoyance

[brunnerh]

Wasn't aware that it behaves differently based on runes vs. legacy.

If it still works in legacy, this at least would not hinder people in using existing code, but the inconsistency in runes mode is odd. Either having no white space should be consistently enforced or it should just work the same as in legacy.

The migration script should also remove the whitespace in case the white space is forbidden.

[Blue-Nomad]

So what is fixed here?

I'd personally like the ability to use spaces in statements. I don't think a framework should enforce a particular style. That's for something like Prettier in my opinion, which I don't use because I like my own formatting.

[paoloricciuti]

So what is fixed here?

I'd personal like the ability to use spaces in statements. I don't think the framework should enforce a particular style. That's for something like prettier in my opinion, which I don't use because I like my own formatting.

That decision was already made to speed up the parser and make the code easier to reason about... it's just about syntax that is supported from the framework

[ErlinEmrys]

That decision was already made to speed up the parser and make the code easier to reason about... it's just about syntax that is supported from the framework

Could that decision be reevaluated, please? It is understandable why it is better for performance and strict code, but from perspective of readability by human eye it is bad.

[paoloricciuti]

but from perspective of readability by human eye it is bad

I was talking about the parser code

[ErlinEmrys]

but from perspective of readability by human eye it is bad

I was talking about the parser code

I was talking about the end-user (programmer) svelte code.

Why is little bit of speed and code readability on parser side more important than all the code in svelte that is and will be written? Looks like I have to write some preprocessor to fix this oversight.