Detached Rulesets and local scope protection

Variables returned from detached ruleset behave differently then variables returned from mixins:

• Variables returned from mixins are copied into caller scope only if they are not present in local scope. However, there is no protection for parent scope.
• Variables returned from detached rulesets are copied into caller scope only if the caller scope does not contain them at all. Both local and parent scope are protected.

Example with detached rulesets:

.wrap-mixin(@ruleset) {
  @b: non-local; // parent scope is protected
  .wrap-selector {
      @ruleset(); // variable returned from detached ruleset is ignored
      visible-one: @b; 
    }
}

.wrap-mixin({
  @b: returned from detached ruleset;
}); // call the whole thing

compiles into:

.wrap-selector {
  visible-one: non-local;
}

Example with mixins:

.ruleset-mixin() {
  @b-mixin: returned from mixin;
}

.wrap-mixin-mixin() {
  @b-mixin: non-local; // parent scope - no protection
  .wrap-selector {
      .ruleset-mixin(); // variable returned from mixin wins over the one defined in parent scope
      visible-one: @b-mixin;
    }
}

.wrap-mixin-mixin(); // call the whole thing

compiles into:

.wrap-selector {
  visible-one: returned from mixin;
}

Expected behavior: mixins and detached rulesets should implement the same caller scope protection. Since detached rulesets are new feature and mixins old one, mixins should win and both of them should protect only local scope.

Tested with lessc 1.7.0 on windows node-js.

[seven-phases-max]

@thejase You don’t need DRs for this. Mixins are capable of the same w/o any DRs (and with more clean syntax): https://github.com/less/less.js/issues/2442#issuecomment-73875782 (and here’s corresponding “no DR” equivalent of your snippet above: https://gist.github.com/seven-phases-max/1f917de67753385c920816740b60c39b).

As for the ticket itself: it’s still considered an issue in https://github.com/less/less-meta/issues/16 (just for language consistency reasons) - so I’ll modify the closing post here accordingly.

[JawsomeJason]

I’d like to offer a valid use case for this: themed/mapped variables:

// MIXINS FOR SETTINGS/GETTING THEMES
#THEMES {
  .set(@name, @vars) {
    #THEMES {
      .get(@@name) {
        @vars();
      }
    }
  }
}


// ESTABLISH THEMES
#THEMES.set(default, {
  @primary: black;
  @contrast: white;
});

#THEMES.set(inverted, {
  @primary: white;
  @contrast: black;
});

#THEMES.set(error, {
  @primary: white;
  @contrast: red;
});

// use themes
body {
  #THEMES.get(default);
  background-color: @primary;
  color: @contrast;
}

.error {
  #THEMES.get(error);

  color: @contrast;
  background-color: lighten(@contrast, 95%);
  border: 1px solid @contrast;
}

IMO, this is far better and cleaner than the redundancy of @primary-default: ..., @primary-inverted: ... variables.