Support customisation for other DSLs like Sass, Less, ...

[AndyOGo]

Feature Use Case

It would be great to tweak the parsers rules for other domain-specific-languages like Sass and Less, to allow for broader syntax support of these, but keep it out of the scope of this repo.

E.g. CSS has no support for negative var() statements, in contrast to Sass and Less, they allow to prefix variables with unary operators like -$var #84

Currently I refactor a stylelint plugin and I need to support not only CSS, but also Sass and Less syntax.

Feature Proposal

As supposed in #82 by @shellscape hooks could be a generic solution to this problem.
Would be great to make them plug-able as well.

[shellscape]

(Sorry I haven't been active lately, lots of moving parts IRL)

I'm not too jazzed by the idea of having separate syntaxes for values. PostCSS supports that for various languages on the whole, but this is a rather granular, specific module that acts as a compliment to PostCSS. But what you can do is inherit from this module to support custom syntaxes.

As far as hooks go, I'm still very open to them. What we need to do is get an RFC going to hash out how they should look and behave. If you'd like to start that off, I'll jump in.

[shellscape]

We've reworked the package and one should be able to inherit from the base classes to extend the functionality of it. Hopefully that will provide people who wish to support other parsers than the standard CSS spec moving forward.

[AndyOGo]

Wau, sounds great! Thank you

[jquense]

Hi @shellscape thanks for all the work you do. Quick question from someone building a CSS dialect on top of postcss. How do you envision extension of the parser working? Some quick experiments extending ValuesParser work well, especially for adding new node types. What i'm not sure about is the best way to extend existing Node types (like adding new operators) without mutating static properties on the classes. Perhaps a more base Parser api that allows configuring the node types? Also it seems like tokenize logic is duplicated between the nodes and the tokenize file, is that intentional or a place where more cleanup could be done.

Thanks!

[shellscape]

There is some logic duplicated with regard to tokenizing because we're reusing PostCSS's tokenizer to take some burden off of this project. (It was agonizing maintaining a separate parser when much of it was the same as PostCSS proper).

Mutating static options isn't good, I agree. If there is anything you need in order to extend the classes in this lib, please raise a new issue and explain the use case, and we can work to accomodate your needs there.