Document Svelte compiler limitations for tooling.

[milkbump]

In response to #726 (comment), specifically:

Writing a custom parser sounds like too much work for such a feature.

I assume there are other issues that have been held back or ignored due to limitations in the Svelte compiler. There are also hacks and workarounds in sveltejs/language-tools packages fighting the Svelte compiler.

Do you think it would be helpful to create a wrapper issue that identifies such issues that could improve tooling? Something like sveltejs/svelte#820 or #83. People could contribute piecemeal where possible or such issues would be considered if there's ever a Svelte 4 overhaul situation.

[jasonlyu123]

Don't know if we need a big thread for this. Most can be traced to few root causes. There're two main limits I can think of to use the svelte compiler:

The compiler is not designed for an editor.

See sveltejs/svelte#4818.

During editing, the likelihood that the code is invalid is very high. But the svelte compiler is designed to throw syntax error to warn the user. Thus the features that rely on the svelte compiler won't work when there's a syntax error.

We did consider writing a dedicated parser for the editor but that seems to be too much work and maintenance burden. So it's not a priority, but I won't say it won't ever happen.

Preprocess being asynchronous.

See #339
The Typescript's language service is mostly synchronous so we can't preprocess before svetle2tsx. That's also one of the big roadblocks of eslint-plugin-svelte3. Maybe a svelte.preprocessSync might help.

[dummdidumm]

I agree with @jasonlyu123's points there, so much that I added them to #83 and updated the title accordingly. This should now give a good overview of what's possible today, what's still missing and what the general limitations are.