lessc *.less overwrites the second Less file with CSS output

[dandv]

I'm trying to use npm scripts instead of grunt and have found that lessc, surprisingly, doesn't supports wildcards in its CLI usage.

With stylus I could do

stylus *.styl

and it would compile each .styl file to a .css file with the same name.

lessc *.less

performs silently but in actuality will obliterate the second file that it globs with the output from compiling the first. All other *.less files will be ignored.

[seven-phases-max]

See for example #1631. I.e. the value of such behaviour in context of CSS compiling is actually questionable. (like "why would I have several interdependent Less files wallowed in the same dir at all?". More over the behaviour of "*.less" is about to be ambiguous - you expect it to compile to independent css, someone else would wait for a single output etc.).

In Less they do not implement something "just because it possible to implement", so args like "tool X does it" are generally useless. An example use-case of where the proposed feature would be important is usually required. (At least to illustrate it's a common expectation and not a rare specific task you can easily handle with your own 5 lines script on top of the Less library or lessc itself)

---

I'm not closing this (as duplicated of #1631) because this can be also considered as bug report for

lessc *.less will obliterate the second file that it globs

(which is sort of expected since lessc *.less expands to lessc 1.less 2.less ... n.less that maps to lessc src dst. Though it does indeed make sense to be fixed/handled in less surprising way).

---

Also see #1181.

[tech4him1]

I am interested is this too, not in the sense that multiple less files get compiled into a single css file -- I can use @imports for that. Where it would be useful is in a case where I have multiple less files that each need to be compiled to their own css file.

[seven-phases-max]

@tech4him1 Just use either of the dedicated node build environments (e.g. grunt, gulp etc.) or any other tool (from dedicated wrappers through GUI editors to shell scripts). lessc itself is a minimalistic utility never meant to "cover it all" (it's more like a demo/test-tool for the Less lib, nothing more). After all, a use-case/project where you compile Less files only is extremely rare (even if you do it right now you'll barely will do it in a half of year or so when things go further, sooner you'll want other post and pre preprocessors, watchers etc and so on).

[matthew-dean]

After all, a use-case/project where you compile Less files only is extremely rare

I wouldn't say that. I've worked on dozens of such projects in the past. And I wouldn't call lessc just a demo or test tool. At least, it's not treated that way in the documentation. It's documented as the official command-line tool.

All that said... I don't disagree at all that it's not the best tool to use, because eventually you'll want something maintainable, which is something where you can set up compilation once and forget about it, as opposed to typing in command-line commands every time. But that's just me. Some developers are very comfortable with command-line tools, and even gulp is a command-line tool. It's just a scriptable one.

But for all the same reasons @seven-phases-max articulated about other tools being available, I'm not sure lessc needs to change, except for the fact that it seems to take wildcards as input, but then produces unexpected output. So if it's already taking wildcards as input, it seems reasonable to compile appropriately-named output.

[tech4him1]

And I wouldn't call lessc just a demo or test tool. At least, it's not treated that way in the documentation. It's documented as the official command-line tool.

That was exactly my thought. Simple builds can use npm scripts instead of a task runner, but tt is much harder to do if you have to compile every file individually, especially with multiple lessc compile options .

[tech4him1]

If #1893 was done, I wouldn't worry about this so much, but as it stands, it is hard to compile multiple less files without a task runner + plugins, etc..

[seven-phases-max]

Either way, personally I believe it all ("a cli-tool with bells and whistles") is anyway best to be made as a separate project (this repo is already overloaded with things - considering a number of active contributors - by now they're literally just 1 (one!)).

And I wouldn't call lessc just a demo or test tool.

I did not say it is. It was "more like a" :). Regardless of what it could be or we'd like it to be it's really nothing but a minimal(istic) command-line-to-API translator.

[matthew-dean]

considering a number of active contributors - by now they're literally just 1 (one!)

Yes, how do we change this? lol

I did not say it is. It was "more like a"

Fair enough. It can still be minimalistic.

this repo is already overloaded with things

Yeah, I'm thinking of taking Rhino out for 3.0, because I have no clue about Rhino usage and we don't have any active maintainers that know anything about it, so there's no good way to update it to 3.0 changes. But that's a side conversation for some other thread.

[matthew-dean]

Btw...

it is hard to compile multiple less files without a task runner + plugins, etc..

Not necessarily. You can write a simple bash script that, when passed in a list of files, runs lessc for every file, like:

for f in *.less; lessc "$f"; done

[seven-phases-max]

Remaking this into a feature request:

lessc should bail out (or at least warn) when it sees file-1.less file-2.less ... args to prevent data loss.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[tech4him1]

#2660 (comment) is still valid, please re-open.

[matthew-dean]

@tech4him1 Re-opened and marked as ready for PR.