Forward intellisense requests to their corresponding language service if they're of their interfaces

[AdaptingAFM]

Description

It is common on my projects that interactable (and sometimes normal) HTML elements share some basic behavior & styles, to the point that when building my UI/UX libraries I find myself making a generic component that is to be instanced when making any variant of the element. Said components' prop extends the interfaces that either Svelte or Typescript provides for the element it features:

<script lang="ts">
	let className: string = '';

	export { className as class };

	interface $$Props extends svelte.JSX.SvelteInputProps {
		class?: string | undefined;
	}
</script>

<input
	{...$$restProps}
	class={className}
/>

And the tooling that Svelte provides is not ideal when interacting with this component, as even though the type any prop of this component accepts would be correctly inferred, the values that are deemed normal and provided by other language services (in this case, HTML's one) would not be suggested.

Proposed solution

Forward/resolve IntelliSense requests to/with their correct language services if they are of the interfaces that TypeScript provide for their language.

This solution would not only solve this use case (which I would argue is to be considered fair and normal) but would also help with CSS and whatnot.

Alternatives

No response

Additional Information, eg. Screenshots

No response

[dummdidumm]

I think the better solution is to enhance the Typescript typings so that the correct attribute values are suggested. This would keep things more maintainable and predictable.

[AdaptingAFM]

I think the better solution is to enhance the Typescript typings so that the correct attribute values are suggested. This would keep things more maintainable and predictable.

What is your reasoning for it being a more maintainable approach? As far as I know, the HTML Language Service is maintained by Microsoft and is on pair with the many specs of the web whilst as any interface we may declare will have to be hand-authored or inspected.

Besides, an argument could be made for this feature to be in the Svelte Tooling ecosystem: a developer who were to make an adapter could be interested in easily mapping TypeScript interfaces to some language service of their interest.

Though I would definitely agree on this mapping being more of a general web concern than one of Svelte on specific: any library that requires the developer of following a composable pattern on their interfaces will always have to face this issue, as a component that craves to comply with the accessibility standards of nowadays will have to expose an API to contextually apply aria & roles specs and whatnot.

So if you agree that this is something that is to be provided by another extension you can close the issue.

[dummdidumm]

More maintainable because less code written
More predictable because how to reliably check when to forward to the HTML service and when not? Check what interface is used? What about interfaces that extend other interfaces? Check the name of the prop - but what if it's just the same name by coincidence? This gets complex quickly.
That's why I'm saying that making the typings more precise so that the correct roles etc are suggested is the better approach in my opinion.

[dummdidumm]

Closing in favor of sveltejs/svelte#7649 which will have enumerated strings for things like input type etc