Add support for "default" variables (similar to !default in SASS)

[pguerrant]

We are considering making the move from SASS to LESS, but the main obstacle for us is lack of a "default variable" feature (see http://sass-lang.com/documentation/file.SASS_REFERENCE.html#variable_defaults_)

This feature is incredibly useful when distributing your SASS code as a library where the variables serve as a sort of "API" for your users. In such a use case all the user has to do is make sure his variables are included up front to override the defaults that he wants to change, and voila! no fiddling with ordering of the (possibly) many files that may contain the variables that need overriding.

I've started working on an implementation, haven't written any tests yet but, hopefully we can use this pull request as a starting point for discussion: #1705

I chose the following syntax:

?foo: value;

as opposed to the SASS way:

@foo: value !default;

for 2 reasons - it's more concise, and the !default syntax may present potential problems with expression parsing on the right hand side in the future (but I could be wrong about that).

The implementation I came up with was surprisingly simple - hopefully I haven't missed anything important. I'd really appreciate any feedback you may have.

Cheers,
Phil

[seven-phases-max]

See The Documentation.

---

Update: Removed my previous comment of this post to not confuse future visitors (here I was trying to answer "how to define a variable if it's not already defined" question and missed the point it's an "XY Problem" and the correct answer for a Sass-like !default is: in Less you don't need anything like that because the necessary functionality ("(re)definition after use") is already provided by the way Less variables work).

[SomMeri]

If you define the same variable twice, the last declaration wins and is valid in the whole scope. So, another option would be to declare variables normally and ask user to include his variables after your library.

library.less

@width: 0;
.mixin {
  width: @width;
}

user.less:

@import "library.less"; //first declaration of @width
@width: 1; //this will override @width defined previously
.class {
  .mixin();
}

compiles into:

.mixin {
  width: 1;
}
.class {
  width: 1;
}

[dongryphon]

Thanks for the feedback on our PR. These solutions would be workable if we had a single thing or a few small things to consume. So let me elaborate on why these solutions are not workable in our case.

We make a large framework of components implemented as a class hierarchy. We declare the variables for each component in its own file... in our base theme. We then "derive" themes from here that want to modify this variables. Users can further do so to tune a theme to their needs.

Further, variables often "derive" from other variables. This most obvious is base-color. We have spent a good deal of time discussing alternatives to the problems of large class hierarchies of components using aggressive variable value propagation combined with themes and their own inheritance behavior.

By far the best solution to these problems is to always define variables as "!default" (in Sass terms). This allows users to simply get in first and set their values before these values are used to calculate further values. The timing is then quite simple to manage for our users. Since this is always the case for every variable in all of our themes, syntax struggles like those suggested above would be quite a burden and also error prone.

We'd love to contribute other features to Less as we continue. I think our (unusually?) large scale use case could be a helpful validation of what is needed to scale up the language / feature set.

I hope you will consider merging this or provide some alternatives that are more declarative in nature. Exploiting scope tricks really won't work for us.

Thanks again for your time and consideration!

[Soviut]

It seems you might be better off defining mixins instead of straight classes. Then, variables can be overridden late in your main stylesheet or another derived theme. That's how I'm able to override things like my gutter widths in my grids after I've imported them.

[dongryphon]

Just to clarify we are talking about variables here only. And we don't have a main stylesheet - we have one per class per theme. :)

Maybe I am not following your suggestion but as an example, one of our theme variable files looks like this:

$panel-base-color: $neutral-light-color !default;
$panel-header-color: $base-color !default;
$panel-frame-border-width: 1px !default;
$panel-header-font-size: round($font-size * 1.15) !default;
$panel-body-border-color: $neutral-dark-color !default;

$panel-light-header-color: #000 !default;
$panel-light-header-background-color: #fff !default;
$panel-light-tool-background-image: 'tools/tool-sprites-dark' !default;
$panel-light-body-border-color: $neutral-dark-color !default;
$panel-ignore-frame-padding: true !default;

This file sets up the various Panel values for a theme that has a chain of base themes 4 deep. Those base themes have their own variable values for Panel but these are loaded first so override them. Unless a user theme derives from this theme and provides values of their own.

This pattern is repeated a lot :)

[Soviut]

Okay, well why not just override @panel-base-color in your main less sheet? LESS variables are global so whichever one happens last is the winner.

@import 'theme.less';

@panel-base-color: red;

Now anywhere that's used in the theme will be overridden. If nobody overrides this down your import chain, then whatever it was originally set to will be the default.

[dongryphon]

We don't have a "main less sheet" :) I appreciate your help and suggestions, but we have had many discussions around this internally and they tend to go on for a bit. Suffice it to say that we believe we need default variable setting as we've proposed here. This feature exists in Sass and we found it very helpful in reducing complexity and providing users flexibility in configuring our themes.

I am curious if all this means that this pull request or some similar derivative would ever be accepted? We'd be happy to tweak the syntax if that is objectionable.

[seven-phases-max]

We don't have a "main less sheet" :)

Simply replace "your main less sheet" in answers above with "any of user's less sheets". So far it seems that SASS !default (whatever syntax it has) is invented to solve a problem that does not exist in LESS.
@dongryphon, I can be wrong of course, but you did not yet ground why you can't use the solution suggested by @SomMeri and @Soviut.

[Soviut]

To put it another way, imagine if you weren't importing and instead had all your variables in the same sheet. That's effectively what importing does. So in that situation, if you had two variable declarations with the same name, the last one in the sheet would win.

@base-color: green;

div {
    background: @base-color;
}

@base-color: red;

Because base colour is declared again at the end, the base-color used in the div will be red. It will compile to:

div {
    background: red;
}

[lukeapage]

This came up before, in fact i believe it was even implemented and we had a pull request from guys who wanted it in bootstrap and they agreed after some discussion that it was a pointless feature in less..

The only thing it allows you to do is for users to define variables before importing. If users define overrides after then it works as if it had a default on it.. that's because even in the imported file it will take the last definition in the same way as css, even if defined after usage.

Its not that much of a burden to users of a library to say they override variables after imports (or import a variables file after imports) vs adding more syntax to less.. we think that is one of the adanvantages of less, that you can do the same amount as sass but most of the time with simpler syntax.

This is counter what a JavaScript programmer might think, but the idea behind it is that its closer to css.

Please can you elaborate on why asking consumers to consider order is not possible or desirable? We will accept features with strong usecases but we have to be rigorous to avoid language and complexity bloat.

[lukeapage]

See #1109 #1104 #313

[Soviut]

And just to clarify, we're not saying "no" by any stretch. We're trying to show his this feature may already exist.

[lukeapage]

I added some info to less-docs