PostCSS Architecture

General overview of the PostCSS architecture. It can be useful for everyone who wishes to contribute to the core or develop a better understanding of the tool.


This section describes ideas lying behind PostCSS

Before diving deeper into the development of PostCSS let's briefly describe what is PostCSS and what is not.



This is a high-level overview of the whole PostCSS workflow


As you can see from the diagram above, PostCSS architecture is pretty straightforward but some parts of it could be misunderstood.

You can see a part called Parser, this construct will be described in details later on, just for now think about it as a structure that can understand your CSS like syntax and create an object representation of it.

That being said, there are few ways to write a parser.

Let's think about why the second way is better for our needs.

First of all, because string to tokens step takes more time than parsing step. We operate on large source string and process it char by char, this is why it is very inefficient operation in terms of performance and we should perform it only once.

But from other side tokens to AST transformation is logically more complex so with such separation we could write very fast tokenizer (but from this comes sometimes hard to read code) and easy to read (but slow) parser.

Summing it up splitting into two steps improve performance and code readability.

So now let's look more closely on structures that play the main role in PostCSS workflow.

Core Structures

API Reference

More descriptive API documentation could be found here