safe-parser limits for unknown at-rules in PostCSS 7 and 8

Short answer

postcss-safe-parser's job is to keep parsing when it hits malformed CSS, but it is not a general-purpose filter for unknown at-rules. Unknown at-rules (e.g. @tailwind, @unknown_rule) are valid CSS syntax — PostCSS parses them into ordinary AtRule nodes without any error, in both PostCSS 7 and 8. Safe-parser only intervenes when the input is syntactically broken (unclosed blocks, bad tokens), at which point it repairs or drops the offending node so parsing can continue.

That distinction resolves most of the confusion in the question: there is no documented, stable discardUnknown option in current safe-parser releases that controls whether unknown at-rules are kept. If you have seen that name, it is likely from an older fork, a wrapper, or a confusion with another tool's option. Treat it as unsupported until you can point to it in the README of the exact version you have installed.

What is confirmed vs. likely

Confirmed, well-established behavior:

• PostCSS (7 and 8) accepts unknown at-rules by design; they appear in the AST as AtRule nodes with their name, params, and children preserved.
• safe-parser only changes behavior on parse errors: instead of throwing, it produces a best-effort AST, typically by dropping or neutralizing the malformed construct.
• When safe-parser removes or rebuilds a broken node, the original formatting and comments inside that construct are lost, and source positions for the reconstructed region will not match the original input.

Likely, but verify before relying on it:

• safe-parser does not emit a PostCSS warning (result.warnings()) when it discards a malformed node. If you need visibility, add a small plugin that walks the AST and compares it against expectations, or diff input/output.
• There is no supported guarantee for source map positions of removed constructs. Assume mappings for repaired regions are absent or approximate, and reconcile them yourself if downstream tooling depends on exact line/column data.

Version differences to expect

Safe-parser releases are paired with PostCSS major versions (safe-parser 4.x with PostCSS 7, safe-parser 5.x/6.x with PostCSS 8). The repair heuristics changed between majors, so the same broken input can produce a slightly different AST after upgrading. Do not assume byte-identical output across the upgrade — snapshot-test your pipeline output before and after.

Verify against your installed version

Because behavior here is version-dependent and not fully documented, run a 10-line check against the exact versions in your node_modules:

const postcss = require('postcss');
const safe = require('postcss-safe-parser');

const css = '@unknown_rule foo { color: red; }\n.a { color: }';
const result = postcss([]).process(css, { parser: safe, from: 'in.css' });
console.log(result.root.toString());
console.log('warnings:', result.warnings());

Expect the unknown at-rule to survive intact (it is valid syntax), the broken declaration to be dropped or repaired, and the warnings list to be empty. Repeat under both PostCSS 7 and 8 if you are mid-upgrade.

One detail that would change this recommendation: if you can share the exact safe-parser version and where discardUnknown came from (a type definition, a changelog, a wrapper library), it would be possible to say definitively whether that option exists in your tree.