`enhanced:img` tag not recognised as `img`

[eltigerchino]

Describe the bug

Following the @sveltejs/enhanced-img docs, we can style images by targeting them as img. https://kit.svelte.dev/docs/images#sveltejs-enhanced-img-intrinsic-dimensions

However, this shows an unused css warning when using the Svelte VSCode extension

Reproduction

https://github.com/eltigerchino/svelte-enhanced-image clone the repo and open the root page in vs code with the svelte extension

Expected behaviour

There should be no warning.

System Info

• OS: [MacOS]
• IDE: [VSCode]

Which package is the issue about?

Svelte for VS Code extension

Additional Information, eg. Screenshots

No response

[jasonlyu123]

This is because there isn't a preprocess config defined. I am not sure if it makes sense if @sveltejs/enhanced-img should expose the preprocessor or if we should add simplify one in the language server that simply replaces "<enhanced:img" to "<img" + ' '.repeat('enhanced:'.length)

[eltigerchino]

CC: @benmccann I'm not sure what the effects of exposing the preprocessor would mean for the enhanced-img package. What do you think would be best here?

[benmccann]

The workaround I've been using is to just define a class directly on the enhanced:img and use that. It'd be cool if we could support this, but I don't have enough experience with language-tools to know what's possible

This is because there isn't a preprocess config defined

Is the problem that we use vite-plugin-svelte to add the preprocessor instead of setting it up in the svelte.config.js file? We do that to simplify setup - you just install the Vite plugin and that's all you need to do.

I don't know what you guys need exposed exactly. The preprocessor depends on Vite, so I'm not sure if that might cause any difficulty?

[dummdidumm]

Things like this make me think that we may be better off by having a special attribute like data-enhanced which signals the preprocessor to preprocess the image? That way we can keep using the img tag and all the checks that come with it work.

[benmccann]

we may be better off by having a special attribute like data-enhanced

<enhanced:img src="./myimage.png" alt="an avocado" />

vs

<img src="./myimage.png" data-enhanced alt="an avocado" />

The former looks nicer and is fewer characters. There's some possibility we could consider the latter, but it's not my first choice.

This is because there isn't a preprocess config defined.

Could language-tools support sveltePreprocess from vite-plugin-svelte? This isn't just an issue that affects enhanced:img, but affects everything using that API. And even if we switch to data-enhanced, it will break again if we add any custom attributes.

[jasonlyu123]

Could language-tools support sveltePreprocess from vite-plugin-svelte? This isn't just an issue that affects enhanced:img, but affects everything using that API

It seems like the API injection is merged with the preprocess options from svelte.config.js in vite-plugin-svelte. It's only accessible within the actual vite plugin part of vite-plugin-svelte and other vite plugins. However, the language server only read the preprocess options from the svelte.config.js, i.e. before merging. There is an option in vite-plugin-svelte to ignore specific plugin preprocess so I am not sure the merging can be moved to the viteProcess function.

[benmccann]

I don't understand. I don't see a method called viteProcess in either this repo or v-p-s.

Do you think it would be possible at a fundamental level? We can modify v-p-s if it would help

[dominikg]

preprocessors defined in viteplugin.api.sveltePreprocess are collected by v-p-s on vite start and added to the config in memory. There is no easy way for language-tools to get access to these and some if not most of them would not work standalone outside of the vite plugin that provided them. The whole point of this api is to allow vite plugins that provide advanced syntax to change that back to valid .svelte code before the compiler freaks out.

[dominikg]

To avoid language-tools or svelte parser to break without this preprocessor, it would be best if the advanced syntax was still compatible, so a data attribute like suggested here would be good for that.