feat: simpler effect DOM boundaries

[Rich-Harris]

Follow-up to #12215. We can make life a lot easier for ourselves by ensuring that branch effects always have a start and end node. In the case of an effect that begins with a non-text/element item, that just means inserting an extra comment node at the front.

Things get simpler as a result. We no longer need a recursive get_first_node function, we no longer need to worry about assigning to effect.nodes.start after effect.nodes has already been created, we no longer need to store nodes object on block effects.

It does mean extra comment nodes in the DOM in some cases. I'd like to try mitigating that by simplifying the common case where a component is the sole child of a block:

{#if foo}
  <Bar />
{/if}

$.if(node, () => foo, ($$anchor) => {
-  var fragment_1 = $.comment(true);
-  var node_1 = $.first_child(fragment_1);

-  Bar(node_1, { $$legacy: true });
+  Bar($$anchor, { $$legacy: true });
-  $.append($$anchor, fragment_1);
});

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: 58f136f

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

[dummdidumm]

The if (DEV) .. hack inside svelte-component.js can be removed as a result of this, which then fixes #12259

[trueadm]

Whilst this makes sense, it also brings back the performance issues and also why I removed the anchor node in my PR to begin with, especially for the common case of:

{#each items as item}
  {@render children(item)}
{/each}

The extra comment node makes large lists much slower during unmount.

[Rich-Harris]

I'm not overly concerned about that, because I'm implementing the optimisation I described above — so far just for components, but I think it should work for other things too. In most cases, there'll be fewer redundant comment nodes.

The additional comment node will only be required in comparatively rare cases where you have multiple items inside a fragment...

{#each things as thing}
  <Foo {thing} />
  <Bar {thing} />
{/each}

...and I think it's okay to sacrifice a little bit of performance in those cases for a) increased performance in common cases, b) more correctness, and c) much simpler code.

[trueadm]

I assume that optimisation is true for this too?

{#each things as thing}
  <div>{…}</div>
{/each}

[Rich-Harris]

That was already the case. See for yourself:

$.each(node, 1, () => things, $.index, ($$anchor, thing, $$index) => {
  var div = root_1();

  $.append($$anchor, div);
});

[Rich-Harris]

For now the optimisation only applies to render tags and components. I'm pretty sure it can apply to other items as well, but I wanted to do some more testing first — in the meantime it seems like a sensible balance of priorities to get this released to fix #12259