fix: remove runtime validation of components/snippets, rely on types instead

[Rich-Harris]

#12452 (comment).

Draft because the render_tag_invalid_argument message is now incorrect, but fixing it requires untangling a few other things. It turns out this particular validation is very broken at present:

• If you have a component like this...

  <Child let:name>
    hello {name}
  </Child>

  ...then $$slots.default is generated, and if you do {@render children()} on the other side, it'll just be blank. Feels like at the very least it should error because children is undefined, as we would for {@render nonexistent()}

• if you do {@render children('bob')} then suddenly it errors. that makes no sense!

• if you do let { children: x } = $props() and {@render x('bob')} it stops erroring again, because we're only looking for an identifier whose name is children. This is brittle as all hell

• as a corollary: you can't declare a {#snippet children(arg)} inside the child component, because you'll get a false positive error

In short: we need to rip the whole thing out. Seems like we'd be better off creating a dummy children prop in the parent that errors on behalf of the child when you try to render it.

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: c27d8de

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]

This doesn't yet update the implementation of server-side snippets to match the types, so we're not yet able to create snippets that curry arguments etc. That can be a follow-up, I reckon

[dummdidumm]

Not adding that feels incomplete - if we make the underlying types more visible, but it's still not actually the real underlying types, then we haven't won anything.

[Rich-Harris]

Gah I thought you'd say that 😅 May not get as far as that this evening, we'll see

[dummdidumm]

Is it possible to split the validation rework out into its own PR? That work seems fairly uncontroversial, while the snippet type thing might take a few more discussions possibly. (Also I'm wondering if it makes sense / is possible to turn snippet arguments into an array under the hood, which also might open up the thing towards spreading)

[Rich-Harris]

good idea — #12521

[Rich-Harris]

Per discussion, removed the controversial snippet changes, and restricted this PR to slightly tweaking the Component type and removing the runtime validation, relying instead on typechecking