search

Fable-Fauna / Fable.Flora

Css theme type provider and tools
MIT License
59 stars 3 forks source link

Sass and postcss support #10

Open nojaf opened 5 years ago

nojaf commented 5 years ago

It would be nice if other styling dialects were supported as well. Perhaps take a look at https://github.com/tonyganch/gonzales-pe, what if the typeprovider could use the AST output to create the type? It would add a dependency to NodeJs but given the nature of this project, I don't think this is a real issue.

musheddev commented 5 years ago

It is certainly possible to extend the parsers to include other dialects, and may in the future. However there is no need to use other, node based AST parsers.

nojaf commented 5 years ago

I was just suggesting it to deal with the sass indentation based format (*.sass) and special things like using @tailwind base; in postcss. If the parser can tackle all those things as well then you don't need it indeed.

kerams commented 5 years ago

Or you could just pipe the input through LibSass and parse the output CSS using the code that's already in place. On the other hand, it's a native dependency, so it would complicated things quite a bit.

musheddev commented 5 years ago

Option 1: Use libsass, process output css. https://github.com/Taritsyn/LibSassHost However, requires packing for all systems and dynamic referencing based on operating system.

Option 2: Using a soft dependency on sass cli or postcss cli, also processing the output css. Have second entry point to the type provider like Flora.PostCss<"postcss.config.js"> or like Flora.Sass<"input.sass"> which of course will throw errors if its soft dependencies are not in PATH. But leaves Flora.Stylesheet<> safe from soft-dependency problems. This would not change packaging. https://github.com/postcss/postcss-cli

Though I suspect most large webprojects will already have some sort of postcss chain that produces an output, which would be ideal for Flora.Stylesheet<>. Though if there is css trimming or other such transforms then you would need a more complex setup.

Option 3: Extend the parsers to parse scss and sass, the ground work has already been laid out. This would only give you the knowledge of an @import tag and will not do any importing and generating properties for the import. Where as with option 1 and 2 you might get that.

It seems that option 2 might be the easiest and more flexible.