Skip to content

Instantly share code, notes, and snippets.

@jonathantneal jonathantneal/ Secret
Last active Mar 18, 2020

What would you like to do?
Maintaining the PostCSS Ecosystem

Maintaining the PostCSS Ecosystem


I am struggling to maintain the dozens of PostCSS plugins and dependencies that make PostCSS Preset Env.

PostCSS Preset Env is experiencing some success as a tool. It is installed nearly two-and-a-half million times a week and trending upward. It has been recently integrated into NextJS by Zeit and it is already used by Create React App by Facebook.

Lots of usage and scarce maintenance

It is currently very time-consuming to track whether a plugin is up to date between GitHub and NPM. The last few months have left many plugins slow to release patches. Others are still out of date.

Currently, lapses in PostCSS plugin releases mean that shortcomings and vulnerabilities to the ecosystem are left in the wild longer. This has also resulted in contributors who identify and even patch these issues being left discouraged by a perceived lack of care.

I have relied on the mentions, persistence, and complaints of the community to publish updates. There are few authors available to actively maintain most of these plugins. Many tools. Many users. Few maintainers.

Dependencies should be benefits, but they are currently blockers.

These many tools also rely on each other. For instance, postcss-nesting appears to be a dependent of nearly a dozen or so other independent PostCSS tools. I couldn’t tell you the number of independent tools using postcss-preset-env, as I couldn’t sift through its nearly 2,369 dependents. The main point is that coordination is an important responsibility of a PostCSS plugin maintainer.

PostCSS plugins also rely on additional CSS tooling; like parsers such as postcss-values-parser and postcss-selector-parser . Currently, when these parsers introduce breaking changes, each plugin has to independently implement the necessary compatibility changes. These changes are made in isolation. Even if I make all of the changes myself, any fix to one implementation must be manually copy and pasted into another.


We would move all of our plugins into a unified repository of plugins, sometimes called a monorepo, where each plugin would be independently versioned by its own directory. These plugins would be maintained in unison by Lerna.

Lerna is a powerful and well known tool for organizing several packages in unison.

Lerna would make it relatively easy to see whether a plugin’s GitHub source is out of sync with its NPM publish. From there, it is relatively easy to push an update to that plugin or several plugins simultaneously.

The impact would be swift and stay swift.

Faster updates would mean that fixes and improvements can be introduced more quickly to the entire plugin ecosystem.

Once in a monorepo, issues that affect one or more repos can be triaged and resolved in unison. This will improve the perceived responsiveness of maintainers, and make it easy for maintainers to support each other. Similarly, updates to external dependencies can be performed in batch. This would allow both the author and the community to more easily catch mistakes or suggest improvements that can be distributed without having memorized the names and locations of every affected dependency.

Next Step

The next step would be get agreement from Andrey Sitnik to copy all of the PostCSS Plugin repositories that I maintain into one unified repository under the postcss namespace. I proofed this concept months ago. I would like this new repository to exist as

Once there, I would go through the process of integrating Lerna so that it can publish new versions of each plugin. Since the current Node LTS is v10 and since most plugins are supporting either Node v6 or v8, it should be safe to publish all new major versions of plugins that exclusively support Node v10 and link to their new location. The existing indenendent repositores would then setup the appropriate deprecation notices that mainly redirect users to the new repository. They would continue to live on in this state for as long as it seemed appropriate.


This comment has been minimized.

Copy link

ai commented Mar 13, 2020

These plugins would be maintained in unison by Lerna.

Is yarn a better alternative than Lerna? I use just Yarn in Size Limit, but maybe I miss the some feature

to copy all of the PostCSS Plugin repositories that I maintain into one unified repository under the postcss namespace

Are you speaking about all “CSS polyfills” plugins?

I like the idea of moving from many small plugins into a few big monorepos. cssnano is a good example of that approach. You can move it to postcss/preset-env.

I do not like the idea to have a single repo for all plugins. But 4-5 repos will be enough. There is a huge political and API gap in tools like cssnano, postcss-preset-env, RTLCSS, and CSS Modules.


This comment has been minimized.

Copy link
Owner Author

jonathantneal commented Mar 13, 2020

@ai, I like the idea of limiting this to the "Preset Env" plugins. I believe I am presently an admin of most if not all of the plugins of that domain.

Would you confirm that I may move the plugins of PostCSS Preset Env to the postcss/preset-env repo? To state the obvious; this would only apply to plugins that I admin, as any others would be out of my jurisdiction; and in no way would I be touching anything belonging to cssnano, RTLCSS, CSS Modules, or any other group. 😄


This comment has been minimized.

Copy link

ai commented Mar 13, 2020


I like the idea (you do not my permission to move your plugins).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.