Nested mixin variable redefinition behavior in LESS 4.x

Answer to the question

In LESS 4.x variables are lexically scoped. When a variable is redefined inside a nested mixin, the new definition only shadows the outer variable for the duration of that inner mixin’s execution. After the inner mixin returns, the outer variable’s original value is restored, so subsequent invocations of the outer mixin see the unchanged value.

Confirmed facts (LESS 4.x)

• Variables follow static (lexical) scoping rules.
• Redefining a variable inside a mixin creates a local binding that does not escape the mixin’s block.
• Each call to an outer mixin starts with whatever value the variable had when the outer mixin was defined (or last reassigned in an outer scope).

Why the behaviour might appear inconsistent

• Build tools that cache compiled CSS, such as less-loader with persistent caching, may store the CSS generated by a particular mixin invocation. If the cache key does not include the runtime value of a variable that was redefined conditionally, a stale cached CSS file can be served, making it look as though the inner‑mixin value leaked.
• When a mixin is re‑invoked after a change to the inner‑mixin’s variable, the compiler may reuse the cached output from a previous run, hiding the fact that the outer mixin’s variable was never altered.

Verification steps (minimal, no installation required)

1. Create a file example.less:

   @color: #f00;
   
   .outer() {
     color: @color;      /* outer value */
     .inner();          /* inner redefinition */
     color: @color;      /* should still be outer value */
   }
   
   .inner() {
     @color: #00f;      /* local shadow */
   }
   
   .a { .outer(); }
   .b { .outer(); }
   

2. Compile with the command line compiler:

   lessc example.less example.css
   

3. Inspect example.css. Both .a and .b should contain color: #f00;, confirming that the inner mixin’s redefinition did not persist.

Diagnostic detail that could change the recommendation

Does your build pipeline use a persistent CSS cache (e.g., less-loader with a cacheDirectory option or a similar caching layer)? If so, clear the cache before re‑running the compiler to ensure you are observing the true lexical‑scoping behaviour.