postcss ships three syntax plugins whose own names promise a compile they refuse to do

Three syntax plugins named for a preprocessor do not compile to CSS

The syntax section contains the trap. It lists postcss-scss as allowing you to work with SCSS, with a parenthetical that says but does not compile SCSS to CSS. It does the same for postcss-sass and postcss-less, each stated as working with the language and explicitly not compiling it to CSS. One entry does compile: postcss-less-engine, which is described as working with Less and DOES compile Less to CSS using true Less.js evaluation, and the capitalisation of DOES is doing the work. So the naming implies a preprocessor and the descriptions correct it, line by line. The consequence is concrete for anyone wiring a build: point the pipeline at an .scss file expecting compiled output and you get a syntax-aware pass, so the file still has to go through a real Sass compiler afterwards.

The browser field switches off five modules, including fs, path, and url

The manifest ships a browser map that replaces specific modules with false:

  "browser": {
    "./lib/terminal-highlight": false,
    "source-map-js": false,
    "path": false,
    "url": false,
    "fs": false
  },

The intent is that a browser bundle should not pull in Node's filesystem, path, or url implementations, nor source map generation, nor the terminal colour helper. Two consequences follow. The field is a bundler hint, so a tool that resolves modules through the exports map without reading browser entries can still pull those in and fail at build time rather than at runtime. And anything that reaches fs or path through a path not listed here is not covered, because the stubs are keyed by exact specifier. For a library that plugins extend, that is the boundary worth knowing before a plugin reaches for a file.

The exports map publishes lib/ internals and ships both module formats

The package entry provides two files, one per module system:

  "exports": {
    ".": {
      "import": "./lib/postcss.mjs",
      "require": "./lib/postcss.js"
    },

Below that, the map lists deep subpaths including ./lib/at-rule, ./lib/comment, ./lib/container, ./lib/css-syntax-error, ./lib/declaration, ./lib/fromJSON, ./lib/input, ./lib/lazy-result, ./lib/no-work-result, ./lib/list, ./lib/map-generator, ./lib/node, ./lib/parse, ./lib/parser, and ./lib/previous-map. Those look like internals, and they are reachable on purpose, which makes them a compatibility surface the project has to keep stable whether or not the names say internal. The other half is the format split: a consumer that bypasses the exports map and deep-requires a lib path directly gets whichever file that path names, not the one the conditions would have chosen.

One author in the manifest, a consultancy in the readme, three funding rails

The maintenance picture is split across three files and they do not say the same thing. The manifest author field names a single person, Andrey Sitnik. The README says PostCSS is built by Evil Martians, described as an American design and engineering consultancy for developer tools, AI, and cybersecurity startups. The funding array has three entries: Open Collective, Tidelift at tidelift.com/funding/github/npm/postcss, and GitHub Sponsors. The consequence for anyone asking who maintains this is that the answer is a company with commercial customers, not a volunteer list, and that a Tidelift entry means there is a paid maintenance channel aimed at companies using the package commercially, sitting beside community funding. That is a healthier answer than a single maintainer, and it is a different one.

The sponsorship block still contains an unfinished editing note

Between the funding links and the plugins list there is a sponsor block, and it reads as if it were pasted in and not finished. The promotional line says CodeRabbit: agentic change management, with Review, prioritize, understand and secure your PRs, and then the trailing sentence let me know if this text is good. That is a note to a collaborator, left in the published file. It is a small thing and it has no effect on the code, but it is worth reading for what it says about the page: the sponsorship and advertising sections are hand-maintained copy rather than something generated, and the project's own funding links are the Open Collective and GitHub Sponsors entries. If you are deciding where to send money, the manifest is the more reliable of the two sources.

Two hundred plugins, and postcss itself does none of the work they do

The plugin categories are the real feature list, and they make the division of labour clear. Solve Global CSS Problem covers postcss-use for scoping plugins to one file, postcss-modules and react-css-modules for selector isolation, postcss-autoreset, postcss-initial, and cq-prolyfill. Use Future CSS Today covers autoprefixer, which pulls its data from Can I Use, and postcss-preset-env. Better CSS Readability covers postcss-nested, postcss-sorting, postcss-utilities, and short. Images and Fonts covers postcss-url, postcss-sprites, font-magician, postcss-inline-svg, postcss-write-svg, webp-in-css, and avif-in-css. Linters and Other cover stylelint, stylefmt, doiuse, colorguard, cssnano, lost, and rtlcss. So the claim that Wikipedia, Twitter, Alibaba, and JetBrains use postcss is a claim about the runtime being present, not about a feature set, and every behaviour is a plugin you select and configure yourself.

Two patches on one day, a three-week gap, and both inside 8.5.x

The release trail is 8.5.30 on 2026-10-12, 8.5.31 on 2026-10-18 and 8.5.32 on 2026-10-26, and the manifest version matches the newest tag at 8.5.32, so here the package metadata and the tags agree. The cadence is still worth noting: fixes land on the 8.5 line, so an older minor is not receiving them. The repository layout explains the rest of the workflow. Linting is eslint.config.mjs, formatting is oxfmt.config.ts, the lockfile is pnpm-lock.yaml with a pnpm-workspace.yaml beside it, and the plugin catalogue and the plugin authoring guide are both in the repository under docs/, as plugins.md and writing-a-plugin.md. That is where you go when you want to write a plugin rather than choose one.

Editorial conclusion

postcss suits a build that wants one transform pipeline with plugins chosen explicitly, and a team willing to read the plugin's own description rather than infer behavior from its name. It is a poor fit if you want SCSS or Less compiled, since the plugins with those names do not compile and only the Less engine variant does, and a poor fit if your bundler ignores the browser field and your code reaches for fs, path, or url. Before you commit, read the parenthetical in each syntax plugin's description, check that your bundler honors the browser stubs, pin the 8.5 line rather than an older minor, and treat the deep exports under lib/ as public API because the package map publishes them.

Frequently asked questions

Official sources

1. License: MIT
2. postcss/postcss on GitHub
3. Project website
4. README
5. Releases