fix: deduplicate children prop from default slot

[dummdidumm]

It's rare, but some components may have a children attribute and receive a default slot content. We previously had undefined behavior in this case, with this PR we're now putting the implicit default content into $$slots.default if we detect there's also a children prop - fixes #10790.
In order to do we need to detect at runtime whether or not a given value is a snippet at runtime, so I moved the "apply snippet symbol" function out of dev and am applying it everytime now. As a consequence, we can also provide a user-facing function, isSnippet, which will help people detect this - part of #9774 update: removed for now.

the following is outdated, now that the isSnippet function is no longer part of the public API. Once it would be, this problem would come back though

This is mostly done, the reason this is in draft mode is because dts-buddy is not creating the correct types. It's inlining the Snippet type on the return of the isSnippet function, but that's wrong because of the unique symbol, meaning the return type of isSnippet and the Snippet type are separate. This will throw a wrong type error:

<script lang="ts">
	import { isSnippet, type Snippet } from "svelte";
	let x = null as any;
	if (isSnippet(x)) {
		let y: Snippet = x;
	}
</script>

{#snippet foo()}
{/snippet}

The snippet type is also inlined in svelte/legacy, and it would be better if it instead would do something like import('svelte').Snippet. I'm not sure if this is really fixable in dts-buddy (unless you have a good idea @Rich-Harris), so my idea for tomorrow is to have some pre and postprocessing applied on the d.ts file generation to get the desired end result.
Update: No longer relevant when not exposing the type, but it will get relevant at some point. I think this requires some dts-buddy hackery, I actually think that TypeScript's doing something wrong here, because it inlines a type that cannot be inlined.

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: 1bdf919

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]

I'm still 👎 on exposing this publicly, at least until there's evidence of significant demand. I think it just encourages bad API design.

[trueadm]

This looks good to me, but I don't have the full context, so will defer to @Rich-Harris

[trueadm]

Having spent time understanding this, this looks good to me!

[Rich-Harris]

I think we need to hold off on this until we have some clarity around #10678 (comment)

[dummdidumm]

How does this relate to this PR? What would need to change? In general, programmatic slots (now snippets) are one of the most requested features, and have been the source of many "hacking into internals" workarounds, so a solution for it would be great

[Rich-Harris]

How does this relate to this PR? What would need to change?

If we had an API for programmatically creating snippets, then either we need to design that API in such a way that the symbol is still present, or we need to come up with some other approach.

In a client-side context the ideal API is something close to this:

mount(App, {
  target,
  props: {
    mySnippet: (firstname, lastname) {
      const element = document.createElement('h1');
      $effect.pre(() => {
        element.textContent = `Hello ${firstname()} ${lastname()}!`;
      });
      return element;
    }
  }
});

In an SSR context that doesn't work, but perhaps that's just something the user needs to deal with:

render(App, {
  props: {
    mySnippet: (firstname, lastname) {
      return `<h1>Hello ${firstname()} ${lastname()}!</h1>`;
    }
  }
});

[dummdidumm]

This sounds like we should expose a createSnippet method which returns a function with said symbol.

[dummdidumm]

Brought this up to date and changed the approach so that we don't need the symbol anymore. Instead, we pass $$slots: { default: true } if we're passing a render children prop and the slot rendering mechanism on the other hand then knows if $$slots.default is true that it should use $$props.children.
I believe we can expand this so that we get better interop in general between slots and render props, which could mean that someone can update to render tags / snippets on one or the other side already and it still works with slots on the other. Will explore that in a follow-up PR.