`skipDuplicates` content dedup silently drops files containing path-dependent at-rules

[Nic-Polumeyv]

When skipDuplicates is on (the default), a file whose content is byte-identical to an already-imported file is skipped, even when its at-rules resolve paths relative to the file's own location. Byte equality is not semantic equality for such files: two identical files at different paths express different targets. The skip produces no warning, so the failure is invisible until someone notices output is missing and bisects their imports.

Reproduction

main.css:
@import "./a/sources.css";
@import "./b/sources.css";

a/sources.css and b/sources.css (byte-identical):
@source "./*.html";

import postcss from "postcss";
import atImport from "postcss-import";

const result = await postcss([atImport()]).process(css, { from: "main.css" });
result.root.walkAtRules("source", (r) => console.log(r.source.input.file));

Output contains one @source (from a/); b/sources.css is dropped. Each file's pattern resolves against its own directory, so the second import is not a duplicate of the first. Controls: with skipDuplicates: false both survive, and making the files differ by one byte also makes both survive, so the content hash in parse-styles.js is the exact mechanism. Reproduced on 16.1.1 and 15.1.0.

@source here is Tailwind's directive, but nothing in this report is specific to Tailwind: any at-rule with path-relative semantics that postcss-import does not own hits the same skip. The reason this lands on postcss-import rather than the at-rule's owner is ordering: the file is dropped during import inlining, before any downstream plugin runs, so no downstream plugin can recover it. Downstream report: vitejs/vite#22386 (Vite bundles postcss-import for @import inlining; the Vite team's position is that this belongs on the postcss-import or consumer side).

Prior art in this repo

This class of bug was found and fixed here in 2015. #67 reported byte-identical proxy files (containing only @import statements) being wrongly skipped, on the argument that their relative imports resolve per-location. The fix (1706c1a, "Not skip files containing import rules") is the hasImport exemption that still guards the dedup today. That exemption encodes the right principle: files whose at-rules carry path-relative side effects must not be content-deduped. It just enumerates the path-dependent at-rules that existed in 2015, which was only @import.

Options

I'm happy to PR whichever direction you prefer, with fixture tests and a README update. In rough order of how much they change:

1. Warn on the skip. When a content-duplicate containing at-rules outside the CSS specs is skipped, emit result.warn(). No behavior change; the failure stops being silent and points at skipDuplicates: false as the escape hatch.

2. Split the two kinds of dedup. In File containing same content shouldn't be skipped #67, the same day skipDuplicates shipped as a boolean, it was pointed out that it conflates skipping the same file twice with skipping different files that share content, and that the two have different use cases. Accepting a value that keeps same-file dedup but disables same-content dedup would let consumers (bundlers included) opt out of the unsafe half without losing the safe half. No default change.

3. Generalize the File containing same content shouldn't be skipped #67 exemption. Extend hasImport to also exempt files containing at-rules that are not defined by CSS, on the reasoning that postcss-import cannot know their semantics are location-independent, so deduping them is not a safe optimization. The failure direction is conservative: under-deduping costs some output size, over-deduping silently drops semantics. The affected set is nearly identical to the files that are broken today. This deliberately does not name any third-party at-rules, in line with the position in Fix conflict with tailwindcss when using @tailwind before @import #449; the check would be against the CSS-defined at-rule names, not a vendor list. Cost: that list needs occasional maintenance as specs add at-rules, and it is a change to default output for the affected files.

Options 1 and 2 compose, and either can ship without 3.

[Nic-Polumeyv]

Opened #602 implementing option 2, since it was the smallest concrete step and makes the comparison easier. If either of the other directions is preferred I'll rework it.

[romainmenke]

Hi @Nic-Polumeyv,

Thank you for all the investigation around your issue.

Does Vite allow you to configure postcss-import?
If so, why not disable skipDuplicates?

[Nic-Polumeyv]

It doesn't. Vite instantiates its bundled copy internally with only resolve, load and nameLayer, and no config surface reaches those options:

https://github.com/vitejs/vite/blob/e16ff3a1199293ac9cdfa6132c08fdea162215f3/packages/vite/src/node/plugins/css.ts#L1616-L1675

It also runs unconditionally on any file containing @import, unshifted ahead of whatever postcss.config.js provides, so adding a second postcss-import with skipDuplicates: false in user config is a no-op: by the time it runs, the internal pass has already inlined and deduped everything.

Vite passing skipDuplicates: false itself would fix this case but would disable same-file dedup for every project at the same time: a file imported at several points in the graph would now be emitted once per import, changing output size and cascade order globally, to fix files that are byte-identical yet distinct. That coupling is why I proposed splitting the modes; with "same-file" available, Vite can pass it and keep the dedup everyone relies on.