Remove support for processors

[jeddy3]

Following on from #3264.

We added support for processors in 7.0.0. Processors replaced the existing extractStyleTagsFromHtml functionality with something more extensible, because we realised that bundling support for all formats that could embed CSS was unsustainable.

The autofix feature was added after the processors system was built. As such, the processor system wasn't designed with autofix in mind and this has led to incompatibilities.

Recently, @gucong3000 proposed using PostCSS's syntax option to extract CSS-like code from the likes of CSS-in-JS, markdown fences, <style> tags and style="" attributes etc. We'd previously only used PostCSS's syntax option for CSS-like languages themselves like Scss and Less, rather than as a means to extract CSS-like code from other formats.

I believe @gucong3000 approach has merit as:

1. it can be used by the whole PostCSS ecosystem (whereas processors are stylelint-specific)
2. it's compatible with stylelint's autofix (unlike processors)

There are currently four syntaxes that extract CSS-like code:

• postcss-html parsing styles in <style> tags of HTML-like files.
• postcss-markdown parsing styles in code blocks of Markdown files.
• postcss-jsx parsing CSS in template / object literals of source files.
• postcss-styled parsing CSS in template literals of source files.

There is a known limitation, though. PostCSS's syntax option only accepts a single syntax, whereas many processors can be used at the same time. I believe @gucong3000 has attempted to work around this limitation with postcss-syntax. When passed to PostCSS's syntax option, it attempts to infer what actual syntax (e.g. postcss-scss, postcss-styled etc) should be used for each file.

Now that we have a replacement for the processor system, should we deprecate it in favour of supporting just syntaxes?

---

I'm going to mention @zabute and @emilgoldsmith as authors of the glamorous and styled-components processors, respectively. I hope you both don't mind. I wanted to give you a heads-up of this discussion in case you have any thoughts you want to share. For example, is there something your processors do that isn't covered by these syntaxes? Incidentally, thank you for your work on these processors and for allowing stylelint to be used by people using CSS-in-JS.

[hudochenkov]

I believe we're not ready to drop processors. Thanks to @gucong3000 we know that we can use syntaxes instead of processors. It renders processors as not needed. Also, it eliminates situations when users can't lint files with a processor and without it using one configuration (styled-components/stylelint-processor-styled-components#187).

We're not ready to drop processors, because most popular processors are not converted to syntaxes yet. I did a quick look at postcss-styled and stylelint-processor-styled-components code. I believe stylelint-processor-styled-components is more robust and cover more edge cases than postcss-styled. I would suggest port stylelint-processor-styled-components logic into postcss-styled. Then update styled-components documentation. And then we can deprecate processors.

I emphasize on stylelint-processor-styled-components, because it's the most downloaded processor. On the second place is stylelint-processor-arbitrary-tags. I don't know what to do with it, because it supports options, and syntaxes don't support options.

[emilgoldsmith]

Thanks for tagging me @jeddy3! I'm not the slightest familiar with PostCSS's syntax parsers so I'm not sure if I can be of much help in the discussion, but it sounds like this has the potential to solve some of the big limitations we've encountered with the processor API. Writing a new library also may bring new life into the project and things like improved interpolation inference could happen which we've in theory wanted to do for a while, but just lacked contribution time to accomplish it. So from that point of view I definitely welcome this new exciting solution, it's definitely some great advantages you point out.

The only thing I'd contribute is just that if you end up deprecating processors, of course make sure that the PostCSS ecosystem has matured enough at that point, and it should hopefully be at least as good as the processor ecosystem is now, so that there'd be no disadvantages in switching. Basically I'm just pointing out the obvious that you shouldn't rush it too much :).

It's pretty exciting though!

[emilgoldsmith]

cc @chinesedfan, @mxstbr

[mxstbr]

We're not ready to drop processors, because most popular processors are not converted to syntaxes yet.

Yeah, as long as there's a long grace period where processors keep working (maybe with a depreciation warning that points to the postcss stuff) I'm fine with this change—just please don't drop the entire option overnight.

[zabute]

Thanks for the mention, @jeddy3.

I find the prospect of having autofix for object styles very exciting and @gucong3000 seems to have done a great job on postcss-jsx. I aslo agree with @mxstbr and @emilgoldsmith: ship processor support along side syntax support and see if the community points out some edge cases that might creep-up before completely removing the processor apis.

[jeddy3]

Yeah, as long as there's a long grace period where processors keep working

Definitely. We'll add a deprecation warning and only remove support in a major release a few months down the line.

[alexander-akait]

sorry for delay
@jeddy3 i think deprecated processors is bad idea. Why? We have some project what use front-matter in top of file and remove their using processor, also some other files can have non standard thing, they can be remove/compiled to normal css/other actions and without processors it will be difficult/impossible.

[emilgoldsmith]

I'm sorry @evilebottnawi I don't think I completely understand what you mean, and what it is processors can do for you that the postcss plugins (given their future maturity) wouldn't be able to handle, could you be a bit more specific?

[nickmccurdy]

The feature isn't being removed, it's being replaced with another API based on PostCSS, which has more community support and can still work like a processor.

[jeddy3]

Status update...

We recently started to drum up community support for the syntaxes by:

• creating and pinning an umbrella issue for all the issues associated with the css-in-js syntax
• improving our documentation on about syntax and working with them
• adding a workaround system for autofix compatibility bugs in the parsers
• forking the css-in-js and markdown syntaxes it into the stylelint organisation

@chinesedfan has kindly created an issue (https://github.com/stylelint/postcss-css-in-js/issues/3) outlining what we also need to add to the postcss-css-in-js to have parity with the processor.

We want to provide first-class support for CSS-in-JS in stylelint, but we'll need help to make that happen.

[ybiquitous]

Close via #6479