Mixins with parameters do not work properly
To reproduce:
Try this code in Playground:
@width: 125px;
.mixin(@container-name; @bp) {
@container @container-name (width < @bp) {
display: none;
}
}
.foo {
.mixin(name, @width);
color: red;
}
Current behavior:
Does not compile with an error
variable @bp is undefined
Expected behavior:
Compiles to
.foo {
color: red;
}
@container name (width < 125px) {
.foo {
display: none;
}
}
Environment information:
-
lessversion: 4.4.2
I also tried to declare the mixin with comma, it doesn't compile either.
.mixin(@container-name, @bp) {
@container @container-name (width < @bp) {
display: none;
}
}
If you add dummy local variable, then the mixin will compile:
@width: 125px;
@bp: 0;
.mixin(@container-name, @bp) {
@container @container-name (width < @bp) {
display: none;
}
}
.foo {
.mixin(name, @width);
color: red;
}
It will also compile if you wrap the variable into the lib:
#values {
@width: 125px;
}
.mixin(@container-name, @bp) {
@container @container-name (width < @bp) {
display: none;
}
}
.foo {
.mixin(name, #values[@width]);
color: red;
}
This is a known limitation in Less's variable scoping: mixin parameters sometimes aren't visible inside nested at-rules like @container, even though they're passed as arguments. Less resolves variables by searching through context frames, but in these nested cases, the mixin parameter frame isn't always included as expected, so you get a "variable is undefined" error. Declaring a dummy variable globally or using a namespace works because it makes the variable accessible in a scope Less can resolve during evaluation. This isn't a syntax issue with commas or semicolons—it's about how Less handles scope in advanced scenarios. There isn't official documentation for this edge case, but it's discussed as a quirk or limitation rather than a bug, and workarounds like yours are commonly used discussion.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
I'm not sure the Dosubot is correct -- this is probably a bug specifically in the @container at-rule parsing & evaluation (or general at-rule parsing & evaluation).