fix: allow multiple optional parameters with defaults

[paoloricciuti]

Svelte 5 rewrite

Closes #12067 i was not totally confident this was an ok fix but i've seen that a similar trick is used in read_type_annotation too so i guess it can be good? Feel free to close if it's not the right fix.

Please note that the Svelte codebase is currently being rewritten for Svelte 5. Changes should target Svelte 5, which lives on the default branch (main).

If your PR concerns Svelte 4 (including updates to svelte.dev.docs), please ensure the base branch is svelte-4 and not main.

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• Prefix your PR title with feat:, fix:, chore:, or docs:.
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests and linting

• Run the tests with pnpm test and lint the project with pnpm lint

[changeset-bot]

🦋 Changeset detected

Latest commit: f952708

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
svelte	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Rich-Harris]

Gah, I thought I had it, but I don't — it fails if the sequence expression isn't the last default:

{#snippet one(a, b = 1, c = (2, 3))}
  {a}{b}{c}
{/snippet}

{#snippet two(a, b = (1, 2), c = 3)}
  {a}{b}{c}
{/snippet}

{@render one(0)}/{@render two(0)}

[paoloricciuti]

Gah, I thought I had it, but I don't — it fails if the sequence expression isn't the last default:

{#snippet one(a, b = 1, c = (2, 3))}
  {a}{b}{c}
{/snippet}

{#snippet two(a, b = (1, 2), c = 3)}
  {a}{b}{c}
{/snippet}

{@render one(0)}/{@render two(0)}

Someone suggested on discord if we could make parse the whole snippet as a function to acorn and then change stuff around.

Do you think it's feasible?

[Rich-Harris]

Seems worth a try, yeah

[paoloricciuti]

Seems worth a try, yeah

I'll try it out and see what i can come up with.

[Rich-Harris]

@paoloricciuti did you mean to force push? looks like previous commits got obliterated

[paoloricciuti]

@paoloricciuti did you mean to force push? looks like previous commits got obliterated

I just rebased main the hash has changed but the content should be the same.no?

[Rich-Harris]

My bad — I thought I'd pushed the failing test in #12070 (comment) but I didn't

[paoloricciuti]

@Rich-Harris i still need to work on a bunch of things but this seems to work...just pushing to get some feedback (maybe there are better ways to do what i'm doing or pre-existing functions i'm not aware of).

[Rich-Harris]

not a new bug, but this logic probably won't be sufficient because these characters could appear inside strings etc. we should probably fix it both here and inside read_pattern...

[paoloricciuti]

Uh right...would prevent the plus and minus between strings be sufficient? It should right?

[Rich-Harris]

strings, comments and regular expressions

[Rich-Harris]

just pushed a couple of tweaks — the test is still failing because a node.end is being replaced where it shouldn't — likely something to do with the amend function that normalizes the output of acorn-typescript

[paoloricciuti]

just pushed a couple of tweaks — the test is still failing because a node.end is being replaced where it shouldn't — likely something to do with the amend function that normalizes the output of acorn-typescript

Uhh I like those changes. Very smart. Btw I think this will also fix #12068

[Rich-Harris]

Opened #12131 for the bracket matching thing, no sense in letting it hold up this fix. Thanks!