No Abort in PostCSS 8: Who Owns the Timeout for a Hung Async Plugin?

Answer: The caller owns the timeout

PostCSS 8’s process() returns a LazyResult that settles only when every plugin’s returned promise (if any) resolves or rejects. The API defines no abort signal, cancellation token, or per‑plugin timeout mechanism. Therefore any time‑bounding must be performed by the caller/integrator.

Confirmed facts

• process() → LazyResult (no AbortSignal or timeout options).
• Plugin work starts lazily on first access of .css, .root, .then(), or .catch().
• Rejecting the LazyResult (e.g., via Promise.race with a timer) does not cancel the plugin’s internal promise.

Likely explanation & recommended steps

1. Create a timeout promise that rejects after the desired duration.
2. Race the LazyResult (or its .then()) against that timeout:

const timeout = new Promise((_, reject) =>
  setTimeout(() => reject(new Error('PostCSS timeout')), 200));

postcss([myPlugin])
  .process(css)
  .then(result => {/* normal path */})
  .catch(err => {/* timeout or plugin error */});

Promise.race([postcssPromise, timeout]).then(...).catch(...);

3. When the timeout wins, the LazyResult is rejected, but the plugin’s pending promise remains untouched; nothing in PostCSS guarantees that the plugin will stop or clean up.
4. If the plugin author documents support for AbortSignal or a similar cancellation mechanism, pass that signal to the plugin and rely on its internal abort logic. Otherwise, accept that the plugin’s side‑effects may continue after the caller’s timeout.

Missing diagnostic detail

Does the specific plugin you are using expose a documented way to abort its asynchronous work (e.g., via an AbortSignal option)? If yes, use that mechanism; if no, the external race shown above is the only safe approach, with the caveat that the plugin may still run to completion.