Preprocessor support?

[tivac]

Given the changes that came out of #3 where it's possible to use real JS objects, it'd be nice to add support for running svelte.preprocess before linting the component.

I want this because we use @modular-css/svelte which is itself a preprocessor that does this:

-<div class="{css.name}"></div>
+<div class="abc123_dep cba321_name"></div>

I don't want to run the full @modular-css/svelte preprocessor while linting, but I have a simplified version that would prevent a bunch of erroneous missing-declaration warnings from svelte by making those values static.

-<div class="{css.name}"></div>
+<div class="name"></div>

I'd really prefer to not have to disable all compiler warnings, and while I could provide a function that filters out just the specific issue we're seeing around the css.foo stuff being able to run a full preprocessor seems more generically useful.

[Conduitry]

There are a few hurdles between here and preprocessor support.

One is that preprocessors are allowed to be async and ESLint plugins have to be synchronous. Relying on something like deasync is not acceptable, because of node-gyp requirements it brings along with it. My current idea for this is to Have a separate process do the preprocessing, and to call that with child_process.execSync. It's hideous but it might work.

The next hurdle is that of sourcemaps. The Svelte compiler doesn't yet support actually doing anything useful with the sourcemaps from preprocessors, so there's not a lot of incentive for them to implement them yet. Of the preprocessors in the wild, I don't really know how many of them provide proper sourcemaps. If there are no sourcemaps, I can't map ESLint warnings and errors back to their original locations. If there are sourcemaps, I still don't expect it to be smooth sailing. I've never worked directly with sourcemaps in tooling before, and I've heard only negative things about the experience from other people who have.

Thirdly, even with sourcemaps mapping the errors back to the original code, there will probably be a lot of times when the autofix for the problem that ESLint will provide won't be applicable. Without an 'unpreprocessor', all I'll know is what replacement will fix the problem in the preprocessed source. I could either disable all autofix suggestions when preprocessors are in use, or just go with the best (quite possibly wrong) guess that the corresponding segment of the original code should be replace with the same string as the preprocessed code would. I don't know which is less likely to irritate people.

Anyway, it would be an uphill battle to implement this, but I do realize that not having it is quite a limitation. Sometime in the near future I intend to dig into sourcemap tools and libraries to see what I can make of that. How well that goes will also affect whether I decide to tackle the first issue about async vs sync.

[tivac]

I'd be fine with a limited version that only support sync preprocessors as a first pass, or even something less structured than svelte.preprocess that allowed for a sync transform of the component before ESLint runs.

Right now I have a custom error handler that just throws away all missing-declaration warnings, and that's not great. I can make do w/o actual preprocessing support if #11 is something you're amenable to, I'd be happy to send a PR for that if it'd help.

[clintwood]

I'm currently using @pyoner/svelte-ts-preprocess to use typescript with svelte3 - is there currently any workaround until this plugin supports a preprocessor? If so how would that be done! Thanks!

[Conduitry]

Linting when using a preprocessor that doesn't return a sourcemap (or something equivalent to a sourcemap) is never going to be possible. It looks like that preprocessor doesn't return one. Even with a sourcemap, there are going to be a number of caveats, outlined in my comment above. I'm working on preprocessor support in this fork but nothing is stable yet.

[rondonjon]

I just stumbled upon this as I was trying to find out why the preprocessed Typescript in my Svelte files is always yielding errors ("unexpected token") on the types 😆

So if I get you right, @Conduitry, this is currently not supported because Typescript itself is at this time only available in Svelte with preprocessing.

Since Typescript is nevertheless a frequent request / addition, would you mind adding a dedicated or more general hint to the README? There is already some info on preprocessors, but somewhere deep in the styles section where people might miss it.

Thanks

[NicoCevallos]

Hey, good news (I guess)
I just created a PR allowing to use preprocessor, but pay attention to the comment in the PR to use it properly!
#62

[mdorda]

Any update? This feature is a deal braker for us :-)