!important for variables

[ESchuderer]

Just like it works for css:

!@color: red;

@color: blue;

a {
  color: @color;
}

Output

a {
  color: red;
}

Syntax Ideas
!@variable: ;
@variable: ;!important

[matthew-dean]

The declaration syntax feels clunky. Can you give an example use-case where you'd need to declare variables twice?

[ESchuderer]

I'm working on a framework at the moment, where I want to be able to merge everything into one css file but also to process every less file as it's own css file. For example I have assets/css/main.css as mergefile and assets/css/forms/forms.css and assets/css/forms/form-groups.css.

That itself is no problem, but if one of the modules is now using paths, everything is screwed up either for the mergefile or the module files. While ../images/ would work for the mergefile, my module would need ../../images/.

I can't think of any way to go around this, while the variables have to be included in each less file.

[lukeapage]

not sure what the problem is with paths? Have you looked at the rootpath option and relativePaths option? foryour other problem, I would do this ?

main.less
    import forms.less
    ...
    import variables.less

variables.less
    @var: 1;

forms.less
    @var: 2;
     .a { test: @var; }

[seven-phases-max]

I suspect this is just yet another variation of "default variables" request.

[matthew-dean]

You know what? The more I think about it, the more I think it's a good idea to do something like this. However, I think it should match CSS syntax.

@color: red !important;

@color: blue;

The use case: we already have this concept of importing a library via (reference) and then choosing what we need and essentially "overriding" what we need. It would be nice to do the same with variables.

As in:

@textColor: red !important; // if this is indeed a Bootstrap variable
@import "bootstrap";

It allows the library to be (somewhat) safe from updates, as I'm not rewriting files in the library, but am still configuring it. Although, would some argue to just do:

@import "bootstrap";
@textColor: red; 

Would that overwrite the variable in the root scope, or would bootstrap have been evaluated by then? Even so, being able to put variables at the top of files is sometimes desirable.

I'm not sure everyone who has mentioned default variables is talking about this scenario, but it occurred to me a couple days ago.

[matthew-dean]

It might be still clunky to add !important to a whole stack of variables, but I think there's an argument for defining variables that take precedence over later declarations.

[lukeapage]

@import "bootstrap";
@textColor: red; 

Would that overwrite the variable in the root scope, or would bootstrap have been evaluated by then? Even so, being able to put variables at the top of files is sometimes desirable.

yes that would overwrite the variable inside bootstrap.

adding this support, I think has several downsides

1. confusion over !important for variables and !important in css - I would expect the important to actually be output.
2. essentially you are adding a whole new level of overrides - by defining an important variable you are saying it cannot be overridden unless by another important. The only use-case I can think of is the one you described - to avoid having to understand variables/imports in less and have the variable declaration first - I think structuring the project so the actual variable definition is last is just how someone should structure a project and trying to work around it is just introducing more issues (e.g. thinking you might be able to re-define a variable - you are better off understanding they are constants and if you need to change a value, define a new variable).
3. It adds a layer of complexity into an area that is already difficult for some people to understand. Given variables behave (somewhat) like properties in css and that !important in css is generally regarded (afaik) as something to avoid and an unnecessary addition to css, for me that points to not extending the concept to less variables.

I strongly suggest this feature request should be closed.

[matthew-dean]

I would expect the important to actually be output.

Yes, that occurred to me as well.

Hmm.... yeah, typically if there's a) another Less way to do it, and b) it adds a bunch of complexity, we tend to not add. I'm fine with closing as I don't feel strongly about it, and you do, so that's fine with me.

[seven-phases-max]

@matthew-dean Yep, and don't forget that beside the standard "last definition wins" LESS behaviour (which makes SASS-like "default variable" facility to be not necessary in normal use-cases), we also have the "scoped variables" design pattern (see 1494, 1706) which does the same but also can be used in a situation when you need a "default variable" not depending on a definition/import order. So it's more like: a) LESS does not need this at all b) It already has similar feature anyway.
The problem with all that "default variable" requests is just that people tend to blindly copy their SASS-oriented (or "whatever-else-imperative") design-patterns not realizing that LESS is not a SASS clone (usually completely missing LESS'es declarative nature especially when it comes to variables).