variable in @import statement

[arnaudgaudin]

The lastest version introduced the possibility to "access the value of an abstract property from a string using { } operators" (section "String interpolation" in http://lesscss.org/#-string-interpolation).

But the problem is that it doesn't work in import statements. It would be great to write code such like this :

//define the template
@mainTemplate: "BaseTheme";

//import the template
@import "_templates/@{mainTemplate}/Config/_ConfigTemplateDefault.less";

I don't know if it is possible to resolve this issue, but it would be great !

[neonstalwart]

additionally it would be good if it could be used in selectors

// in vars.less
@themeName: "my-theme";


// somewhere else
// using escaping and interpolation but any syntax that works would be fine by me
~".@{themeName}" {
    .stuff { ... }
}


// produces
.my-theme .stuff { ... }

[anru]

+1 @DarkoBa. Needed feature

[arnaudgaudin]

Just changed my username from darkoba to arnaudgaudin due to professionnal reasons ;-)... @anru, thanks for the +1, can't wait for this feature !

[anru]

I implemented this feature - in the near future (probably Monday) I make pull request

[anru]

see #426

[cj]

any update on this?

[tirsen]

Is this happening or not happening? It would be really useful.

[neonstalwart]

my use case for selectors was just added 3 days ago in 93b23d2

[bdalziel]

I would also like to use variables for @import statements. Until support is added, it would be nice to document that variables are not interpreted for import @Statements; I tried numerous variations before finding this issue:

@COMMON-ROOT-DIR: "../../../../../common/trunk";

// All these don't work.
@import "@{COMMON-ROOT-DIR}/css/variables.less";
@import url("@{COMMON-ROOT-DIR}/css/variables.less");
@import `"@{COMMON-ROOT-DIR}" + "/css/variables.less")`;

etc.

[klebba]

+1

[nucleardreamer]

+1 please please please!

[MokoJumbie]

+1 please fix

Lots of folks looking for this

#835
#707
#835

..to mention a few

[Arech]

This is a must have feature.
Please, implement it!

[anodynos]

Is this the cause of the erroneously translated URLs ?

My file is

projectroot/assets/less/myStyle.less"

and the the output is simply

projectroot/assets/css/myStyle.css

myStyle.less is importing

@import "../../lib/bootstrap/less/bootstrap.less";

The less files are in all in here

projectroot/lib/bootstrap/less/bootstrap.less

The problem is URLs like

../img/glyphicons-halflings.png

are erroneously tranlated to

../../lib/bootstrap/less/../../lib/bootstrap/less/../img/glyphicons-halflings-white.png

instead of

../../lib/bootstrap/less/../img/glyphicons-halflings-white.png.

I am using WinLess, not the browser.

[lukeapage]

changed to high priority because of all the requests and closed above duplicates

[notsure]

+1
+1
+1
+1
+1

[EvHaus]

+1

[crisu83]

+1

[adamjgrant]

+1 indeed.

[joenivl]

+1

[lukeapage]

yes.. its been marked high priority..!

It would be nice to sort out all the import related bugs (and this feature request) at the same time - presuming other committers think its a good idea. I think its a good idea.

[keymholio]

+1

[adamjgrant]

I actually need some of these features sooner rather than later, so I'm going to be dragging over pull requests into my own fork.

Less.js Canary anyone?

[lukeapage]

If a pull request is provided without API changes I will pull it, otherwise it will have to wait till I get round to looking at this.

[bdalziel]

I have a node.js instance running this:

https://github.com/SlyTrunk/less.js-server

So I can curl a local URL for .less files to be compiled to .css. Doesn't matter what language you're writing your site in.

[lukeapage]

I used to maintain dotless but its too much to port everything I do here.
Been meaning to wrap less.js in a .net wrapper and offer it as a
replacement. I did that with jslint for the jslint4visualstudio extension I
wrote.. should be relatively easy.

[rolandjitsu]

@bdalziel That is not an optimal solution. It would work for a local environment where only I work, but as a team I don't want to make them install Node and NPM and then RECESS or whatever is needed. Especially when we deploy the code to production or another team takes over. Backend developers are not very found of adding new installs to the project as they usually automate the deployment process and the LESS minification is done runtime.

[bdalziel]

My team shares a development machine so it's optimal for us. You could also have a single server and have the node module return the compiled CSS over http rather than writing directly to the file system. Just sharing what works for me - understand it won't work for everyone.

[Soviut]

If you're using pre-processed languages (like LESS, CoffeeScript, Jade, etc.), your developers should expect to have to run some sort of local build tool in order to compile their code. LESS is a node module first and foremost. The fact that it has a browser implementation at all is just lucky.

Check out Grunt for doing local builds, and also consider automating the deployment of tools for your developers.

[rolandjitsu]

We are not using less.js to compile the LESS in the browser, that would cost the performance a lot. We are using a C# implementation that serves the files (CSS / JS) based on the env and it handled versioning and caching of the files. Plus, it stores in memory, not on the disk. Things are a bit different in .NET world.

Personally I'm using Grunt for minifying, compiling LESS / Stylus, linting, testing, etc. But that doesn't work very well when it comes to working with TFS and VS, which locks all the files and can only be worked on in VS. Otherwise we have to manually checkout for edit each file we are about to work outside of VS.

Though, yesterday we found a pretty good tool for System.Web.Optimization which is what we use to handle whatever means bundling scripts and styles, minifying, transforming, etc. It's called BundleTransformer, it works really well and it uses V8 to parse the node scripts (like less.js). This way we always can use the latest versions of these preprocessors and we can still take advantage of in memory storage, caching and versioning. (I know that Node is not yet capable of doing in memory storage of the styles or scripts runtime, which is what I would like to have because I use node for small projects most of the time).

@bdalziel Yes, that might work for your team, but in our case it would never work.

@Soviut We cannot use Grunt for builds, we compile C# / C++ on build. And you cannot handle deployments of such projects with Grunt, VS handles that for us with just a few configs. We have to all kinds of scripts and commands during deployment on the remote server which is something that Grunt cannot do (it's a JavaScript Task Runner), plus we use IIS to serve content and it doesn't play well with node if we were to use some Node server instance on the server that listens for incoming connections so we can run commands. And doing this with Node would consume a lot of time and resources whereas using TFS, VS, or other Microsoft tools we have that out of the box.

Of course this applies for large projects, because for small websites that I do in my personal time, I prefer to work with Node and Express or Ruby and Sinatra, lately, that allows me to use Grunt for running deployment tasks and other local operations like lint, test with Karma the frontend functionality, unit test my Node scripts, etc. I really enjoy working with Node, because it's very close to what I've been used to, but it just doesn't play very well with .NET, which sometimes makes me very sad.

[Soviut]

I did say that Grunt is good for LOCAL builds. Even then, you can have grunt to compile to a "dist" sub-task which can conveniently put all compiled files in a "dist" folder. Visual Studio or a build step should have no trouble dealing with precompiled and minified files your grunt task generated.

Grunt can do anything your build scripts can do since it can call shell scripts on windows, OSX or Linux exactly the same way visual studio does. Grunt and LESS compilations can be handled on the server. Finally, IIS is just another server like Apache or Nginx. It has all the same rules for redirecting, rewriting and aliasing URLs that any other webserver has.

I used to do a lot of .NET development, and it can easily play well with node. So can Python, so can Ruby, so can Go, etc.

[matthew-dean]

You can use any LESS compiler to build the CSS as you go, and build your C# website project with the CSS as you normally do. So basically, edit LESS outside of VS, save to CSS. Build everything else in VS.

[Soviut]

Also, you should also be able to call external tasks from your build scripts. There are pre/post compile hooks that should allow you to easily call a grunt task or the lessc compiler directly every time someone hit's F5 in VS. Similarly, you should be able to do the same thing on deployment build scripts.

[pixelass]

I got

// need to keep this in here since LESS does not allow vars in import statements from imported files
@COMPONENTS:        "components";
@REGIONS:           "@{COMPONENTS}/regions";
@CONTAINERS:        "@{COMPONENTS}/containers";
@MODULES:           "@{COMPONENTS}/module";
@BLOCKS:            "@{COMPONENTS}/block";
// collections in components
@LESS_COLLECTION:        "/less/_collection";

.IMPORT (@COMPONENT: "foobar") {
    @import "@{CONTAINERS}/@{COMPONENT}/@{LESS_COLLECTION}";
}

// add @imports here
// e.g.
.IMPORT("foobar");
//line above is a testcase


>>
SyntaxError: variable @COMPONENT is undefined in /Users/*******/less/_collection.less on line 17, column 1:
16 // e.g.
17 .IMPORT("foobar");
18 //line above is a testcase

while

@import "@{CONTAINERS}/foobar/@{LESS_COLLECTION}";

works perfectly

as well as

.IMPORT (@COMPONENT: "foobar") {
    //@import "@{CONTAINERS}/@{COMPONENT}/@{LESS_COLLECTION}";
    :after {
        content: "@{COMPONENT}";
    }
}

// add @imports here
// e.g.
.IMPORT("foobar");
//line above is a testcase

BTW using lessc with Less v 1.5.1

[matthew-dean]

So, variable interpolation of imports is still not working in imported files. @lukeapage What's the "master issue" that you're tracking this on, since this one is closed and there are related duplicates?

[ltoshev]

Hi

I'm having the following issue with @imports too.

I have in a file

file base.less:
@dFolderPath: "/d"; // default value
@import "@{dFolderPath}/dependencies/font-awesome-3-2-1/font-awesome.less";

And then I want to redefine the variable from outside:

like this
@dFolderPath: "/d/2020"; // versioning of the d folder path
@import base.less

But the value of @{dFolderPath} is not redefined and it still has the default value. This works for variables not used in imports. Can you fix it for imports?

Any comments how easy is to fix this, I just need to have it! Point me in the code of the less so I can fix it?

[matthew-dean]

@ltoshev There's currently a known bug about this. This feature only works correctly when used in the root document, unfortunately.

[luishdez]

Well same problem here, I have a bower component that references to other bower component ( bootstrap ).

So if I use the component "standalone" I have Eg:
@import ../../bower_components/bootstrap , but if used as a part of other project the path to the reference will change so I have to make truly stunts adding extra subfolders to match the paths in both cases. This could be solve easily with @import '@{bower_path}/ ... and defining bower_path in the parent project. But variables don't override on import statements and only work in the main file, so they are pretty useless

[saas786]

+1

[rossbb]

Forgive my ignorance, but I am trying to define a variable for @import based on a database parameter. So if clientID=X, @theme=X. Any idea how I can do this?

[fny]

@rossbb: Currently, you can use variables inside of import statements within the same file.

// client_123.less

@clientID: '123';
@theme: 'happy';

@import "clients/@{clientID}/variables";
@import "themes/@{theme}/base";

After this issue is resolved, you'll be able to use those variables in import statements of other imported files too.

[tublitzed]

+1

[lukeapage]

@tublitzed and all, I just finished #2246 and it should fix all these use-cases. There is one situation that won't work, to do with overriding variables which i will add to the pull request, but would appreciate any testing of that branch as its a tricky thing to do.

[lukeapage]

Released in v2 beta 2.
The only thing not implemented is that you cannot override a variable defined and used in a sub file with a variable in the parent file. but if you use it in the parent or ovveride in a sub file it is fine. More details on #2246

[joeSaad]

👍 for @import "@{url}/less/file.less"

[seven-phases-max]

@joeSaad Just in case, you do realize this feature is implemented quite a while ago, do you?

[jeradrutnam]

I'm still having an issue with this. It works fine with less v2.7.3. But breaks in less v3.9.0.

This doesn't work,

@defaultSiteVariables: "~semantic-ui-less/themes/default/globals/site.variables";
@import "@{defaultSiteVariables}";

@siteDir: "~semantic-ui-less"
@import "@{siteDir}/themes/default/globals/site.variables";

This works,

@import "~semantic-ui-less/themes/default/globals/site.variables";

I'm compiling this using less.render and using less-plugin-rewrite-import to fix node_module import

---

Aha, just noticed that issue is being discussed here: #2772

But is there any workaround ?

[mihmilicio]

Having the same issue using Less with Angular 8. Any updates?

"less": "3.9.0",
"less-loader": "5.0.0"

I tried updating to latest, didn't work.

The console outputs the following:

./src/styles.less (./node_modules/@angular-devkit/build-angular/src/angular-cli-files/plugins/raw-css-loader.js!./node_modules/postcss-loader/src??embedded!./node_modules/less-loader/dist/cjs.js??ref--16-3!./src/styles.less)
Module build failed (from ./node_modules/less-loader/dist/cjs.js):



@import  "assets/less/@{client-dir}/_variables.less";
^
Maximum call stack size exceeded
      in C:\localpath\styles.less (line 709, column 0)

[SheldonLaw]

Having the same issue using Less with Angular 8. Any updates?

"less": "3.9.0",
"less-loader": "5.0.0"

I tried updating to latest, didn't work.

The console outputs the following:

./src/styles.less (./node_modules/@angular-devkit/build-angular/src/angular-cli-files/plugins/raw-css-loader.js!./node_modules/postcss-loader/src??embedded!./node_modules/less-loader/dist/cjs.js??ref--16-3!./src/styles.less)
Module build failed (from ./node_modules/less-loader/dist/cjs.js):



@import  "assets/less/@{client-dir}/_variables.less";
^
Maximum call stack size exceeded
      in C:\localpath\styles.less (line 709, column 0)

same issue in

"less": "3.11.1",
"less-loader": "4.1.0"

I found it ! My import has interdependence which will cause loop error. SO variables import can find this hiding error.

// a.less
import "b.less";

// b.less
import "c.less";

// c.less
import "b.less";

Is ok when I don't use variables import, but error throw when :

// a.less
import "b.less";
@path: "yourpath_whatever";
import "@{path}";

// b.less
import "c.less";

// c.less
import "b.less";

[matthew-dean]

@SheldonLaw Causing a loop (Maximum call stack exceeded) is a bug. You should file as a new issue.