Which mechanism controls plugin visitor execution order in PostCSS 8's single-pass API?

Plugin ordering in the single-pass visitor model

PostCSS 8 replaced the per-plugin tree walks of version 7 with a single-pass visitor API where all plugins traverse the AST together. Each plugin registers listeners for node types such as Declaration, Rule, or AtRule, and the engine invokes those listeners during one unified traversal.

Array order as the primary control

Documentation confirms that within a given node type, visitor callbacks fire in the order plugins appear in the array passed to postcss(). This makes array position the main lever for sequencing transformations—for example, ensuring a custom-property fallback runs before autoprefixer processes the same declaration.

Missing declarative dependency mechanism

PostCSS does not provide a built-in way for plugins to declare dependencies on one another. Teams must manually decide, document, and maintain the correct plugin order whenever transforms interact, which becomes fragile as the plugin list grows or when plugins are shared across projects.

Does the single-pass API guarantee consistent cross-node-type ordering beyond the array sequence? Which patterns have proven reliable for expressing implicit dependencies without a formal mechanism? How do teams verify ordering assumptions when plugins are updated independently?