Add ability to pass variables to CLI compiler

[ProLoser]

To do cache-busting app-wide, I need to add a ?123 to the end of all my import statements. I see that you guys added import interpolation, however, this requires that I must set the cache-busting value in my CSS (which seems frustratingly odd).

It would be nice if I could pass a variable as a cli argument that would then become the cachebusting value (such as the git sha1, etc).

Something like:

lessc -vars={cachebust:123} somefile.less

[Soviut]

There are already discussions and future implementations of cli variable passing #1655

That seems strange that you'd need to cache bust your import statements. Can you explain your setup since you're compiling locally, but do you have imports that are changing frequently and would otherwise be cached at the server?

[ProLoser]

So the ultimate goal is just traditional cache-busting.

That in mind, lets say we've got a project with a bunch of internal assets (.less) and a handful of third-party libs (.css). Now being a smart dev, I like to package this into one big minified resource that I send altogether. The THING is that while the .less imports are merged and placed directly into the output css file, the .css imports are retained in the output file. Now, it's completely unreasonable for me to go and copy/rename/whatever every single third-party css file to .less just to avoid this behavior.

In retrospect, perhaps a better request would be to add an option so that *.css imports are not retained in the output css?

[Soviut]

I just checked lesscss.org and apparently since 1.4 you can force imports to act as different types.

@import (less) "lib.css";

You can also inline your css with:

@import (inline) "file.css";

It also sounds like you really need a build tool like Grunt or something similar, rather than manually packaging stuff up.

[rjgotten]

To do cache-busting app-wide, I need to add a ?123 to the end of all my import statements.

While I'd personally like the ability to add variables to the commandline (mostly to work as compilation switches such as for conditionally including support for ancient IE browsers), the use-case you're presenting here is flawed. You shouldn't use the query string to perform cache busting this way because of proxies.

Read: http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/

You should make sure your version is part of the actual URL path, in which case CSS import statements that use relative paths would already solve your problem. (Not that actual CSS import statements inside external stylesheets are actually a good idea in the first place...)

[ProLoser]

This is an offline local app. We don't do proxies. And if I want to rev filenames as your article suggests then this still poses a problem.

[Soviut]

Still, if you're compiling everything to a single flat CSS file, what's the problem? And if this is a local app, why exactly do you need cache busting?

[ProLoser]

Importing CSS (inline) is breaking the URLs to their assets.

[lukeapage]

done