Support Svelte's $$Generic type

[ptrxyz]

I'm not sure if this is a bug or a feature but I think svelte-eslint-parser doesn't support Svelte's $$Generic type to type component properties.

Relevant information is probably this: sveltejs/eslint-plugin-svelte3#127

[ota-meshi]

Thank you for posting issue.

The RFC about $$Generic don't seem to have been merged yet.
sveltejs/rfcs#38
I don't want to fully support it yet to avoid a lot of breaking changes.
If you want to support it, we can add it as an experimental feature.

--

Related to sveltejs/eslint-plugin-svelte#390

[ptrxyz]

I see, so it is on the radar somehow but needs some deeper digging. Thanks a bunch.
Feel free to close this issue or keep it open to keep track of $$Generic.

For anyone stumbling across this: for now I simply workaround by defining $$Generic globally in my eslintrc:

...
        env: {
                ...
        }, 
        globals: {
		$$Generic: 'readonly'
	},
...

[dummdidumm]

@ota-meshi I'm exploring an alternative syntax for this currently, which would look like this:

<script lang="ts" generics="T, X extends string">
  export let items: T[];
  export let key: X;
</script>

From an implementation-perspective, how hard would it be for svelte-eslint-parser to support this syntax?

(I'm not saying it's decided that we switch to this syntax yet, but I want to have as much feedback as possible before making the decision)

[ota-meshi]

Thank you for letting me know.
Vue team is also exploring generic attribute, so I'm looking into how to support it with the vue-eslint-parser.
(I'm the maintainer of eslint-plugin-vue and vue-eslint-parser.)

The current idea is to insert virtual code like this:

type T = unknown;
type X = string;

In TypeScript, this might generate the wrong type like the following example code, but I anticipate no problem within the scope of the checks used in typescript-eslint.

<script lang="ts" generics="T extends string | number">
  let val: T = 42 // It's a type error in TypeScript.
</script>

↓ Virtual code

type T = string | number
let val: T = 42 // It's not an error. Also, `val` is inferred to be of type number.

If it works, I think svelte-eslint-parser can handle it the same way.

[wvhulle]

@ota-meshi I'm exploring an alternative syntax for this currently, which would look like this:

<script lang="ts" generics="T, X extends string">
  export let items: T[];
  export let key: X;
</script>

From an implementation-perspective, how hard would it be for svelte-eslint-parser to support this syntax?

(I'm not saying it's decided that we switch to this syntax yet, but I want to have as much feedback as possible before making the decision)

It would be nice to keep the $$Generic in inside the script. If you have a lot of generics you can't just write them on one line.

And can you keep the types interactive and highlighted as a generics property?

[connerdassen]

Why is this not supported?
The now obsolete eslint-plugin-svelte3 had this added a year and 8 months ago.
Defining $$Generic globally in eslintrc gets rid of the undefined error but causes problems later on because it is assigned an "any" type, leading to no-unsafe-member-access errors later on when trying to use the type defined by $$Generic

[dummdidumm]

It's not supported yet because it's still experimental, which is a valid choice.

[probablykasper]

Would love to update to Svelte 4, but the deprecated eslint-plugin-svelte3 doesn't support it. Was I unknowingly using an experimental feature, or is it just not supported anymore? Are there any plans for when to address it?

[theodorejb]

@probablykasper Switch to eslint-plugin-svelte.

[probablykasper]

@theodorejb I would love to, but it sounds like $$Generic is unsupported, without any workaround

[jjnp]

Would you be open to a PR to add support for the feature, even if it's still just an RFC? If you are focused on other tasks, which I of course understand, I'd try to look into what I can do to help the feature along. We're using generics in multiple production apps and having this break with the upgrade to svelte-4 is a step back for our project setup...

[ota-meshi]

I think we can add support for Generics to svelte-eslint-parser as an experimental feature. Please consider submitting a PR. However, please allow it to be opted in using something like parserOptions.
However, $$Generic seems to have been discarded from the RFC, so we won't be adding support for it in the future.

[niemyjski]

It's pretty bad dev experience when the official docs say to use these features but then linting fails out of the box when using these features...

[jjnp]

It's pretty bad dev experience when the official docs say to use these features but then linting fails out of the box when using these features...

Yes... I'm looking into writing a PR to add support for it, but I haven't gotten around to it yet since I'm not yet familiar with developing eslint-plugin related things^^

[AlbertMarashi]

Yeah also ran into this issue. I thought I was doing something wrong but apparently not

[AlbertMarashi]

Temporary workaround for those people who's T is unknown/generic

<script generics="T" lang="ts">
// TODO: REMOVE WHEN https://github.com/sveltejs/svelte-eslint-parser/issues/306 IS FIXED
// eslint-disable-next-line no-undef, @typescript-eslint/no-explicit-any
type X = T | any

export let options = X[]

This will get the errors to disappear

[AlbertMarashi]

@Rich-Harris will this be fixed in Svelte 5 because of the new props system?

[dummdidumm]

$$Generic is deprecated in favor of the generics attribute, which should be supported in this parser at some point. For more info see #306 (comment)

[AlbertMarashi]

I see. Is there any issues that need resolving that perhaps I could help work on?

[dummdidumm]

I'll defer to @ota-meshi and @baseballyama for this question

[ota-meshi]

I think if someone works on this implementation, it can be added as an experimental feature.
#306 (comment)