Is it bad practice to override LESS variables?

Question

I'm using Twitter Bootstrap on a project at the moment, including the LESS files and compiling with some additional LESS code that we've written.

The latest release has meant we need to override some of the Bootstrap LESS variables. One option here was to maintain a modified copy of Bootstrap which we patch on each release.

But I note that it's possible to override a variable defined in an @import LESS file by re-declaring the variable after the import statement.

E.g.:

@import "twitter-bootstrap/bootstrap.less"; // Restore base font size to pre 2.1.1 defaults @baseFontSize:          13px; // Add some custom LESS code here 

Is this bad practice? Is it an artifact of the way the LESS compiler works, or an intended part of it? I couldn't find much information on this, although I did find the following two references:

Because of a bug in the Less compiler, you can override the “constant” value of a variable by changing it after it is initially declared.

http://rubysource.com/how-to-customize-twitter-bootstrap%E2%80%99s-design-in-a-rails-app

and

Customize the columns and gutters by overriding these three variables (after the grid.less import has been declared).

http://semantic.gs/

The LESS site itself says that variables are 'constants':

http://lesscss.org/

Note that variables in LESS are actually ‘constants’ in that they can only be defined once.

But then I see other sites using this approach.. It's certainly easier than maintaining a vendor branch and seems to work fine with less.js.

Would appreciate any thoughts on whether this is a bad thing to do or not!

Answer 1

Ok! One of the above issues led to a discussion of the intended behaviour, and it turns out that overriding LESS variables is fine.

Your declarations will overwrite each-other in the same scope in CSS; The same is true for LESS.

https://github.com/cloudhead/less.js/issues/297

Like in CSS, overriding within a scope is an intended way to use LESS.