fix: include container-query type in patch output

[bibixx]

Problem

The patched container-condition and query-in-parens types both reference <container-query> in their syntax, but container-query itself is never included in dist/index.json.

How this happened

In b670b0cac (#1466), when the package was first created, css-tree didn't have container-query in its base grammar. It appeared in the diff as type: "added" and was correctly included in the output.

In a0880e31b (#1792), css-tree was updated to ^3.2.1, which added container-query to its base grammar. Since both sources now defined it identically, diff_sets() excluded it from the diff, and it was removed from the patches. But container-condition and query-in-parens still reference <container-query> in their merged syntax — creating a dangling reference in the patch output.

Why it crashes

In css-tree's base grammar, container-condition is defined as:

container-condition = not <query-in-parens> | <query-in-parens> [ [ and <query-in-parens> ]* | [ or <query-in-parens> ]* ]

The patch replaces this with the newer spec definition:

container-condition = [ <container-name>? <container-query>? ]!

This new syntax references <container-query>. But container-query isn't in the patch output — because both css-tree and webref now define it with the exact same syntax, so the diff step sees no difference and excludes it. When consumed with a css-tree version whose base grammar doesn't include container-query, there's no definition for it anywhere, and css-tree throws:

Error: Bad syntax reference: <container-query>

This crashes tools like stylelint entirely (not a lint warning — an unhandled exception) when validating @container rules.

Fix

Added container-query to the manual compatibility patches in apply-patches.mjs, following the existing pattern for dashed-ident and unicode-range-token. This ensures the patch output is self-contained for the types it references.

Also added a test that verifies container-query is present in the output and that @container preludes validate without error.

[romainmenke]

Hi @bibixx,

This PR description reads as if it was created with the assistance of an LLM.
We do not allow that in this project.

---

This crashes tools like stylelint entirely (not a lint warning — an unhandled exception) when validating @container rules.

Can you create a reproduction for the underlying issue?

[bibixx]

Hey, yes. Indeed the PR description was created with some help of an LLM. Sorry didn't know about that. But with the code itself I was thoroughly going through myself. I'll create repro in a moment.

[bibixx]

It does surface in a pretty specific dependencies combinations (which we have actually encountered in our project, and the fix for it will be to just update the stylelint to latest version) but this still seems like a bug in the postcss plugin.

Here's repro: https://github.com/bibixx/container-query-repro

[romainmenke]

and the fix for it will be to just update the stylelint to latest version

That is what I suspected :)

We did add the peer dependency version constraint to better communicate this.
But given that this package is just a bunch of JSON files and doesn't use csstree itself it isn't a direct dependency.

So I guess we can close this?

---

Keep in mind that an LLM will happily write fixes for non-issues and thereby waste time of (unpaid) OSS maintainers.

I will gladly look into any issue and review any PR, but I won't even look at a diff produced (partially) by an LLM :)

[bibixx]

The logical issue is still there. It probably won't happen again but only now the code itself is actually correct.
And the issue itself I've found myself, and fixed myself.

It could still happen in theory if the versions are misaligned. So I mean it's up to your discretion. You're the maintainer ;)

[romainmenke]

A true fix would need to be done in package managers.
Currently there is no way to communicate to a package manager:

• X is an optional peer dependency
• when X is present, ensure it has at least version Y

But maybe it is fine to make the peer dependency required?
In practice users of this package will (almost) always use csstree.

[bibixx]

Okay, so the assumption (even though might not be always true, since, as you mentioned package managers aren't perfect) is that the users will always use the plugin version corresponding to the csstree version?

[romainmenke]

Yes, if you use it with a version that is outside the version constraint you will have issues and those will not (can't) be fixed.

There is no way to have a correct syntax definition as a whole with mismatched versions.

[bibixx]

Got it. Closing then