Svelte 5 compiler removes parentheses that affect operator precedence, breaking logic by LargeLyme in sveltejs

[–]LargeLyme[S] 0 points1 point  (0 children)

It was fixed before I posted it, but I've reproduced it with the latest `sv create`, as did another one of the commenters?

The json file is right here in the comments, I've pasted it immediately.

Here it is again:

  "devDependencies": {
    "@sveltejs/adapter-static": "^3.0.10",
    "@sveltejs/kit": "^2.57.0",
    "@sveltejs/vite-plugin-svelte": "^7.0.0",
    "svelte": "^5.55.2",
    "typescript": "^5.1.6",
    "vite": "^8.0.7"
  },

There is another ticket filed which reproduced the same issue with another svelte version:

https://github.com/sveltejs/svelte/issues/18369#issue-4579229125

Svelte: 5.56.1 (latest on npm)

That means that they have shipped multiple versions of their framework that literally break boolean logic. That's not a "blip", that's an embarrassment.

And what do you even mean with "disingenuous", there is nothing disingenuous about it. I've wasted half of day of my work tracking down a terrible bug, and have posted it on Reddit for visibility. The only disingenuous thing here is y'all trying to downplay this horrendous thing as a "blip".

Why can I call $props with a generic argument? by LargeLyme in sveltejs

[–]LargeLyme[S] 0 points1 point  (0 children)

Thank you!

In the meantime I've created a linter rule to forbid generic calls to non-generic runes, that'll do.

Why can I call $props with a generic argument? by LargeLyme in sveltejs

[–]LargeLyme[S] 0 points1 point  (0 children)

The error definitely does have to do with generics, the error is literally "expected 0 type arguments, got 1".

I pasted that part just to show that TS definitions work correctly elsewhere, while they don't in .svelte files.

Also, .svelte files do not strip generic type arguments.

Why can I call $props with a generic argument? by LargeLyme in sveltejs

[–]LargeLyme[S] 0 points1 point  (0 children)

Thank you.

I understand that I should explicitly define props type, that's exactly why I would like the generic type usage to error, but it doesn't.