Proposal: parse <style> contents using PostCSS

[marekdedic]

Description

Hi,
as suggested in sveltejs/eslint-plugin-svelte#402, I'd like to add support for rules around styles to eslint-plugin-svelte. However, since I am going to be implementing style parsing to do that, I thought maybe it would be better to provide it as part of svelte-eslint-parser?

I am not sure if there's any way of making this compatible with ESTree, but I'm not sure that is actually necessary or even a good idea. I just think that having an AST for styles may make it easier to create eslint-plugin-svelte rules that work with styles.

[ota-meshi]

I think it difficult to convert a <style> AST to an ESLint compatible AST.
Supporting different CSS preprocessors (e.g. SCSS, Sass, Less, Stylus) is difficult.

I don't think we need an ESLint compatible AST to implement the rule in sveltejs/eslint-plugin-svelte#402.
It just uses CSS preprocessors to convert it to CSS and uses postcss and postcss-selector-parser to extract the class name.

[marekdedic]

Hi,
yes, I agree it would be difficult to convert the PostCSS AST into an ESLint AST - so let's not do that.

I totally could do all of this in sveltejs/eslint-plugin-svelte#402, however, I have the feeling this won't be the last rule that needs to inspect the <style> block at least in some part - ESLint is not Stylelint and it shouldn't be, but there are things in Svelte that connect the template with the script and the styles.

So what I am proposing is to essentially move the parsing part into svelte-eslint-parser - yes, the result would be a PostCSS AST kind of "hanging" from an ESLint AST node, which is not the best, but I think it is better than duplicating the parsing in every rule that needs to read/manipulate <style>. And you mentioned preprocessors - yes, they are one more reason to do it this way actually - let's solve different style "languages" once in the parser as well - the rules are going to need to support them either way...

[ota-meshi]

So what I am proposing is to essentially move the parsing part into svelte-eslint-parser

Hmm. If it doesn't produce an ESLint-compatible AST, I think that producing such an AST with this parser will only confuse plugin authors.
Also, at the moment, there are very few eslint-plugins that use the AST generated by this parser, and I think eslint-plugin-svelte is the only plugin that wants to use the result of <style> parsing. So I don't think parsing <style> in plugins is currently a problem.
I think it should at least generate an ESLint-compatible AST. However, ESLint may expand AST compatibility in the future.
https://github.com/eslint/rfcs/tree/main/designs/2022-languages

[marekdedic]

Hmm. If it doesn't produce an ESLint-compatible AST, I think that producing such an AST with this parser will only confuse plugin authors.

Yeah, I get that, that's not good... Do you think naming the property something like postcssAST would help?

Also, at the moment, there are very few eslint-plugins that use the AST generated by this parser, and I think eslint-plugin-svelte is the only plugin that wants to use the result of <style> parsing. So I don't think parsing <style> in plugins is currently a problem.

I agree that it's currently not a problem, I'd like to prevent it from becoming one :D I think in general, styles are an integral part of svelte code and rules aimed at svelte will want to look at them, sooner or later (I already have another rule proposal in mind that'd need this :D). I think it would be better to have one common way of dealing with them, rather then each plugin/rule designing their own... If you disagree with this basic assumption behind my wanting to include this as part of the AST, then I think we won't agree - and of course, you have the final word as the maintainer, I just hope to persuade you with my arguments :)

---

Looking at the ESLint AST, is that really that complicated? Looking at the docs, do I understand it correctly that this would boil down to the range and loc properties? - the docs mention ESTree compatibility, but, well, there isn't an ESTree for styles...

Thanks for the link, seems very interesting, but also far away :D

[marekdedic]

Oh, sorry, looking at the ESTree docs, it would mean type in addition to range and loc. But the postCSS AST already has that :)

[marekdedic]

Actually, I already managed to convert the PostCSS AST to be ESLint AST as well :D

[marekdedic]

Closed by #340