feat: add ComponentExports utility type

[FoHoOV]

With the type change for bind:this on components (related issues are this language-tools issue and 13430).
Recommended way is to do this (per this comment):

<script lang="ts">
    import CloneWorkflowDialog from './dialogs/CloneWorkflowDialog.svelte';

-   let cloneWorkflowDialog : CloneWorkflowDialog;
+   let cloneWorkflowDialog : ReturnType<typeof CloneWorkflowDialog>;
</script>

Since we currently have the Component type exported by svelte that has the Exports we can rely on that and do this instead:

<script lang="ts">
    import CloneWorkflowDialog from './dialogs/CloneWorkflowDialog.svelte';
    // in a utility type, preferably provided by Svelte package itself. 
+   type ComponentExports<TComponent extends Component<any, any>> =
+	TComponent extends Component<any, infer TExports> ? TExports : never;
 
-  let cloneWorkflowDialog : ReturnType<typeof CloneWorkflowDialog>;
+  let cloneWorkflowDialog : ComponentExports<typeof CloneWorkflowDialog>;
</script>

Whats the problem with using ReturnType?

This is the safer/forward-compatibale way that the svelte can decide on the type.

Svelte 5 rewrite

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]

⚠️ No Changeset found

Latest commit: 1024ae0

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[webJose]

Note that some previous change (which may be the one being referred to here) broke @testing-library/svelte's TypeScript support. I mention this here because perhaps it could be verified.

[bdmackie]

Very cool, so much nicer to code with. I get this warning in VS code, does this have to be suppressed globally or is there a better way to avoid it?

dropdownComp1 is updated, but is not declared with $state(...). Changing its value will not correctly trigger updatessvelte(non_reactive_update)

Update: I believe it's required to ignore the above warning. See my comment here for my use case and the related discussion: #13104 (comment)

[FoHoOV]

Very cool, so much nicer to code with. I get this warning in VS code, does this have to be suppressed globally or is there a better way to avoid it?

dropdownComp1 is updated, but is not declared with $state(...). Changing its value will not correctly trigger updatessvelte(non_reactive_update)

Update: I believe it's required to ignore the above warning. See my comment here for my use case and the related discussion: #13104 (comment)

If I understand correctly this is not related to this PR, this is just a utility type, to type the bind:this (since let component: Component is not the correct type anymore), this will be forward compatible if the type is gonna change in the future as well.

[bdmackie]

Very cool, so much nicer to code with. I get this warning in VS code, does this have to be suppressed globally or is there a better way to avoid it?
dropdownComp1 is updated, but is not declared with $state(...). Changing its value will not correctly trigger updatessvelte(non_reactive_update)
Update: I believe it's required to ignore the above warning. See my comment here for my use case and the related discussion: #13104 (comment)

If I understand correctly this is not related to this PR, this is just a utility type, to type the bind:this (since let component: Component is not the correct type anymore), this will be forward compatible if the type is gonna change in the future as well.

I tried to say it was just a use case connection (adoption friction for bind:this) for context if anyone was prioritising/triaging, so not technical/code related to this PR specifically. Apologies if it was unhelpful.