(feat) add svelte-preprocess as fallback

[dummdidumm]

#86

No preprocessor apart from ts supported yet

We have to discuss what to support out of the box and what not, because the preprocessor (rightfully) says it is your responsibility to install less / babel etc. So if we would support all of them, we would add quite a lot of dependencies to our project and also bloat the package size.

So what would be the subset we support?

For me mandatory:

• typescript (already supported)

Optional:

• babel
• less
• sass (does that work? There are some very system specific things going on with that package..)

As an alternative, we could maybe do some hacks to reroute the module resolution of svelte-preprocess to the user workspace. Chances are very high the user would have installed the needed preprocessors because he needs them either way to get the project to compile.

Another alternative would be to not add this dependency to our project but instead try to find the dependency inside the user's workspace. I think most users use svelte-preprocess in their webpack/rollup config, so there is a high chance they have it (and all required other dependencies) installed.

Opinions?

Side note: I added skipLibCheck to tsConfig because svelte-preprocess fails the strict type checks, and also because of the peer dependency types. I hope that is okay for you?

[jasonlyu123]

I think we don't need babel. If the syntax can't be handled by typescript, it probably is some tc39 proposal syntax that needed to be installed separately as a plugin by the user.

if we don't include scss and less. the style features would still work. but the svelte compiler will throw parsing error. That can be suppressed by preprocessing everything in the style tag to white space. In that way, the 'unused-CSS' warning would be sacrificed

[dummdidumm]

Babel: good point.

If we don't include less/scss then ... : Good idea. Additionally we could then add a warning diagnostic like "you need to add a svelte.config.js to get style svelte diagnostics".

Edit: Maybe we can do a combination of the possibilities:

1. Try to find svelte.config.js.

• If found -> good.
• If not, try to find svelte-preprocess in user directory.
• If not found there, fall back to our version of it.

2. Try to parse svelte file.

• If everything works -> good.
• If parser error -> look at position and message.
  • If inside script, append some additional info that preprocessor setup might be wrong.
  • If inside template, show as is.
  • If inside style, retry compilation with blanked out styles and add info about possibly wrong preprocessor setup.

Things left to find out: What if the preprocessor throws an error? Can that happen?

[jasonlyu123]

Supplement my thought on babel. If the user is using js syntax that is not supported by svelte, for example, optional chaining, we probably can hack svelte-preprocessor to transpile as if it's typescript.

[dummdidumm]

I now added a "try finding svelte-preprocess-fallback and enhanced the error messages with some suggestions on possible error causes. I did not add "try parsing babel as typescript" or "blank out style and try again" logic. This can be done in a different PR, if we feel it's necessary.

Before I merge this in: Can someone please read the enhanced error messages and tell me if they are concise/understandable?

[dummdidumm]

No objections it seems, so let's try it with this one.