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-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.
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.