postcss-sorting keeps your stylesheet in a declared order

Everything is off until you turn it on

postcss-sorting is a PostCSS plugin to keep rules and at-rules content in order, and the most important line in the options documentation is that the plugin has no default options and everything is disabled by default. That is a deliberate design choice rather than an oversight. A sorting plugin with opinions baked in would reorder every stylesheet it touched, which would be an unwelcome surprise in a build pipeline, so this one requires you to say what you want. The options are an order key, which specifies the order of content within declaration blocks, a properties-order key, which specifies the order of properties within declaration blocks, an unspecified-properties-position key, which says where properties not named in properties-order should go, and throw-validate-errors, which defaults to false and makes the plugin raise configuration errors rather than showing them and ignoring them. The grouping vocabulary includes custom properties, dollar variables, nested rules and nested at-rules.

Installing it and running the CLI

The install is a development dependency alongside PostCSS itself:

npm install --save-dev postcss postcss-sorting

To use it from the command line you also need postcss-cli:

npm install postcss postcss-cli postcss-sorting --save-dev

The configuration lives in a postcss.config.js, and the shape of it is what tells you the plugin's model of the world:

export default {
	plugins: {
		'postcss-sorting': {
			order: [
				'custom-properties',
				'dollar-variables',
				'declarations',
				'at-rules',
				'rules',
			],

			'properties-order': 'alphabetical',

			'unspecified-properties-position': 'bottom',
		},
	},
};

Here the content order puts custom properties first, then dollar variables, then declarations, then at-rules, then rules, and the properties within a block are alphabetical, with anything not mentioned parked at the bottom. Once the config exists, the rewrite is one command:

npx postcss --no-map --replace your-css-file.css

The --no-map flag avoids writing a source map next to the reformatted output.

Comments travel with the node they belong to

The first caveat is about comments, and the rule is specific enough to be worth knowing before you run the plugin. A comment that is before a node and on a separate line is linked to that node. A shared-line comment is also linked to that node, and a shared-line comment means one located after a node and on the same line as that node. So in a block where a shared-line comment trails a declaration, that comment belongs to the declaration it trails, and the two separate-line comments above the next declaration both belong to that next declaration. The consequence is that sorting moves comments with their property rather than detaching them, which is the behaviour you want, and it is the behaviour that a naive line-based sorter would get wrong. The example in the documentation shows a rule with a trailing comment on one property and two stacked comments above another, which implies the comments follow their properties when the block is reordered.

Ignored at-rules and CSS-in-JS interpolation

The second and third caveats protect code that must not be moved. Some at-rules are ignored, and the named examples are the control and function directives in Sass, with the reason given plainly: rules will not touch content inside these at-rules, as doing so could change or break functionality. A function directive holds a value, and reordering the declarations inside one can change what it evaluates to. For CSS-in-JS, the rule is narrower and cleverer. To avoid breaking the logic when a rule has a template literal interpolation, properties are sorted only among neighbouring properties before or after the interpolation. The documented example shows z-index and top sorted as one group, position and display as a second group, with the interpolation acting as the separator, and inside a nested rule a property whose value uses an interpolation, as in top with a computed pixel value, does not break the grouping because the interpolation is in the value rather than the property name.

Syntactic reach and the stylelint relationship

The plugin supports CSS and SCSS through postcss-scss, CSS-in-JS through postcss-styled-syntax, and HTML through postcss-html, with the README noting that most likely any other syntax added by other PostCSS plugins works too, since the plugin operates on the PostCSS AST rather than on a text format. The same author maintains stylelint-order, and the relationship is the important part of the design. stylelint and stylelint-order lint stylesheets and tell you whether the order is correct, and they can also autofix, while postcss-sorting does the ordering as a build step. The README recommends Prettier for formatting stylesheets, which is a division of labour: Prettier handles whitespace and formatting, stylelint-order handles the declared order, and this plugin enforces it. Editor integrations exist as Sublime Text, Atom, VS Code and Emacs plugins, though the README notes that all of them seem not to be maintained.

The package shape and the benchmark harness

The package is postcss-sorting at version 10.0.0, MIT licensed, authored by Aleks Hudochenkov, and it is an ES module with a single exports entry pointing at index.js. PostCSS itself is a peer dependency at ^8.4.20, so the plugin does not install its own copy of PostCSS, which is the right arrangement and also means your PostCSS version is your choice. The published files list includes lib, index.js and the type declarations, with the test files and the .d.ts files inside lib excluded from the package. The development setup is thorough: Jest 30 with the jest-light-runner, ESLint 9 with a config of the author's own, Prettier 3, husky 9 for git hooks, lint-staged for staged changes, and TypeScript 6 for type checking, with a test-full script that runs lint, types and test together. The benchmark is part of the repo rather than an afterthought, with a benchmark directory and a tinybench dependency, and the README explains that it times only the plugin on real stylesheets, synthetic edge cases and hot helpers, and that parsing and cloning are not measured.

Where postcss-sorting is the wrong choice

Three cases. The first is a project with a small stylesheet and no complaint about its order, where running a sorter adds a build step and a configuration surface for no benefit. The second is a codebase where another tool already owns the ordering, since running a PostCSS sort and a stylelint autofix against the same files in the same commit is a recipe for churn, and the plugin's own author points you at stylelint-order for the linting side of the same idea. The third is a project whose ordering is load-bearing in a way the plugin cannot know about, where a rule's order changes the cascade outcome for a selector, and where the plugin will happily move it because the plugin only knows the order you declared. Against a formatter like Prettier, the difference in approach is that Prettier is deliberately order-blind and will not reorder anything, while this plugin treats order as a semantic property of the stylesheet that you declare and enforce.

Editorial conclusion

postcss-sorting is a good fit for a team with a large stylesheet whose order has drifted, or for anyone who wants the order of properties to be a written rule rather than a habit, since the same configuration can drive both the PostCSS pass and stylelint-order. It is a poor fit for a small stylesheet nobody complains about, and a poor fit for a codebase whose ordering is decided by another tool, since two sorters fighting is worse than one. Check three things before you switch it on: that you are ready to accept the plugin's defaults being empty, because everything is disabled until you configure it, so a misconfigured run can reorder nothing at all or reorder everything; that your CSS-in-JS blocks are handled by postcss-styled-syntax if you rely on them, since the plugin sorts only among neighbouring properties around an interpolation; and that the at-rules you rely on are not in the ignore list, because Sass control and function directives are left untouched on purpose, because moving content inside them could break the function.

Frequently asked questions

Official sources

1. hudochenkov/postcss-sorting on GitHub
2. Issues
3. License: MIT
4. README
5. Releases