Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using a generic type as an argument to a Snippet breaks types generation of a component #12202

Closed
tommyminds opened this issue Jun 27, 2024 · 4 comments · Fixed by #12262
Closed
Assignees
Milestone

Comments

@tommyminds
Copy link

tommyminds commented Jun 27, 2024

Describe the bug

When I use a generic type as an argument to a snippet, svelte-package does not properly generate a Component.d.ts file for my component anymore.

While I understand the following test case is a bit weird, I do have several components where I use the type of one of the properties to determine the type that is passed to subsequent snippets.

Reproduction

<script lang="ts" generics="T">
	import type { Snippet } from 'svelte';

	let {
		data,
		someSnippet
	}: {
		data: T;
		someSnippet?: Snippet<[T]>;
	} = $props();
</script>

<div>{@render someSnippet?.(data)}</div>

Logs

No response

System Info

System:
    OS: macOS 14.5
    CPU: (8) arm64 Apple M1 Pro
    Memory: 72.55 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.19.1 - ~/.nvm/versions/node/v18.19.1/bin/node
    Yarn: 1.22.22 - ~/.nvm/versions/node/v18.19.1/bin/yarn
    npm: 10.2.4 - ~/.nvm/versions/node/v18.19.1/bin/npm
    pnpm: 9.3.0 - /opt/homebrew/bin/pnpm
    bun: 1.1.13 - /opt/homebrew/bin/bun
  Browsers:
    Chrome: 126.0.6478.127
    Safari: 17.5
  npmPackages:
    svelte: ^5.0.0-next.1 => 5.0.0-next.166

Severity

blocking an upgrade

@paoloricciuti
Copy link
Member

I suspect this has something to do with language-tools I'll try to take a look later

@tommyminds
Copy link
Author

I found other cases where types are not generated anymore. There also seems to be an issue using ComponentProps for components that have a Snippet on their props. For example the following causes the outer component to not generate types anymore.

Outer.svelte

<script lang="ts">
	import type { ComponentProps } from 'svelte';
	import Inner from './Inner.svelte';
	let { foo }: ComponentProps<Inner> = $props();
</script>

Inner.svelte

<script lang="ts">
	import { type Snippet } from 'svelte';
	let {
		foo,
		footer
	}: {
		foo: string;
		footer?: Snippet;
	} = $props();
</script>

@dummdidumm
Copy link
Member

Investigating this. For some reason TypeScript seems to want to unpack the types when using the ComponentProps type, likely because of the infer used in there. That in combination with the generated d.ts output of the default export of components leads to TS breaking down somewhere. This not only happens for Snippet, it can happen for other imported types, too.
Not sure what a good fix could be yet.

@dummdidumm dummdidumm self-assigned this Jun 28, 2024
@dummdidumm dummdidumm added this to the 5.0 milestone Jun 28, 2024
@dummdidumm
Copy link
Member

Investigated this further. Ultimately this is a TypeScript limitation: For reasons that I don't understand TypeScript is not able to correctly backtrack imports if the declaration file is written of the form

declare module "svelte" {
  class Foo {}
  export { Foo }
}

TypeScript will then error with something like Exported variable 'X' has or is using name 'Foo' from external module "svelte" but cannot be named.
If the module is declared like this instead

declare module "svelte" {
  export class Foo {}
  export {}
}

The error does not appear. It seems that the extra indirection is too much for TypeScript to know where to find the import and then errors.

The fix is to revert Rich-Harris/dts-buddy#82 in dts-buddy and instead add export {} at the end, which has the same outcome with regards to which types can be imported.

dummdidumm added a commit to Rich-Harris/dts-buddy that referenced this issue Jul 2, 2024
sveltejs/svelte#12202 revealed that TypeScript has a harder time tracing imports when they are indirectly exposed, e.g. `function foo(): void; ... export { foo }` instead of `export function foo(): void;`, which can lead to bugs down the line. Ultimately this is a TypeScript limitation but in the meantime adding a lone `export {}` along `export function/const/etc` statements has the same effect as #82
Rich-Harris pushed a commit to Rich-Harris/dts-buddy that referenced this issue Jul 2, 2024
* Revert "Fix exports (#82)"

This reverts commit b9435de.

* fix: better way of preventing unintended exports

sveltejs/svelte#12202 revealed that TypeScript has a harder time tracing imports when they are indirectly exposed, e.g. `function foo(): void; ... export { foo }` instead of `export function foo(): void;`, which can lead to bugs down the line. Ultimately this is a TypeScript limitation but in the meantime adding a lone `export {}` along `export function/const/etc` statements has the same effect as #82

* fix tests
dummdidumm added a commit that referenced this issue Jul 2, 2024
#12202 revealed that TypeScript has a harder time tracing imports when they are indirectly exposed, e.g. `function foo(): void; ... export { foo }` instead of `export function foo(): void;`, which can lead to bugs down the line (such as in that issue). A new `dts-buddy` version fixes this, which in turn fixes #12202

This also adjustes the `Snippet` type and turns it into an interface, which makes for better intellisense: The type will be unpacked in less situations, resulting a more readable and named type.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants