less / less/less-meta

Unify Mixin and DR behaviour (and related Functions stuff)

Open
#16 79 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
No language data
Stars
5
Forks
0
PR merge metrics
No merged PRs in 30d

Description

As dissucussed in #2767, current DR and Mixin call result (visibility of their internal entities in the caller scope) is somewhat inconsistent. In particular, mixin calls exposes both internal mixins and variables, but DR calls keep its variables hidden:

Mixin:

.my-red-theme() {
    .button() {
        color: red;  
    }

    @color: red;
}

.btn {
    .my-red-theme();
    .button();            // OK
    border-color: @color; // OK
}

DR:


@my-red-theme: {
    .button() {
        color: red;  
    }

    @color: red;
};

.btn {
    @my-red-theme();
    .button();            // OK
    border-color: @color; // Error
}

The proposal is to match both (per #2767 by exposing DR variables too).


The exposed variables ("callee variables") have the lowest priority (i.e. never override caller's local or parent scope variables), thus the change will not break any existing Less code.

Edit: My mistake above: callee variables do override caller's parent (incl. global) variables, thus the change is breaking for snippets like:

@my-red-theme: {
    @color: red;
};

@color: blue;

.btn {
    @my-red-theme();
    color: @color; // blue -> red
}

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the discussion in issue #2767 and comparing the Mixin and DR examples in this issue. Trace how DR and mixin calls expose entities in the caller scope, including the related Functions behavior. Done means the visibility rules are consistent and the documented breaking case is covered.

Written by the indexing model from the issue text.

Assessment

Domain
compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.