rootpath option doesn't work when url has variable

[zuzusik]

I have following code

background: url('@{imgPath}fr.png') no-repeat;

For this code rootpath option doesn't work, it gets compiled to

background: url('img/Path/Variable/Value/fr.png') no-repeat;

If I remove @{imgPath}, then everything is OK

Less version 1.6.1

[jhnns]

This is also a problem when using bootstrap as less library since they're referencing their icons dynamically.

[seven-phases-max]

src: ~"url('@{icon-font-path}@{icon-font-name}.eot')";

That way it would not work anyway simply because ~"url(...)" is not recognised as url(...) value. Escaped strings are not a subject for an evaluation or modification of any kind (except @{var} expansion).
In fact they made this on purpose: see twbs/bootstrap#10941 (so no rootpath is applicable there).

[jhnns]

Yep you're right!

[seven-phases-max]

Btw., speaking of the initial issue report by @zuzusik. I've just tested this with v1.7.0,
lessc --rootpath=whatever/ ...:

@imgPath: 'img/Path/Variable/Value/';

.z {
    background: url('@{imgPath}fr.png') no-repeat;
}

and it compiles as expected to:

.z {
  background: url('whatever/img/Path/Variable/Value/fr.png') no-repeat;
}

So I guess this can be closed (could it be just some OP mistake?).

[seven-phases-max]

Closing as not reproducible (feel free to reopen if you have an example of not working --rootpath and url interpolation combo).

[jhnns]

Thx anyway 😄.

Btw: Bootstrap reverted it

[seven-phases-max]

Yep. But it still looks like ideally and eventually we will need three --relative-path options (two current values + "true off") So that we could be able to get url links just "as they are" w/o any processing, i.e. this is what they simulated with ~"url(...)", and indeed for a complex projects this might be a better way to handle such things.

[jhnns]

Why is using variables insufficient?

[seven-phases-max]

Because we have to specify them :) And because we have to know we have to specify them (and/or use --relative-urls). I suspect the issue will keep rising again and again if things remain as they are now.
(Though it's hard to say for sure w/o deeper investigation with a few complex test projects to compare all possible methods, hence at least I'm not planning to dig into this any time soon).

[jhnns]

Well, the only reason why I'd use variables is if I wanted to provide a way to override the path (which is a common requirement for css frameworks like bootstrap). And in this case all overridable variables should be at once place.

But I agree, it will surely come up from time to time again.