Less.js: No output with option --depends in version 2.7.x

[gkraser]

If run lessc 2.7.x with option '--depends' (lessc in.less out.css --depends), depends writen in console, output file - not writed.
In version 2.6.1 - all ok.

[seven-phases-max]

This was implemented in #2830. So what is the use-case of using both ("depends list" and "css") simultaneously?

[jdufresne]

The first run of the Makefile, CSS files _must_ be generated as they do not yet exist. As a byproduct of producing the CSS files, the dependency files are created simultaneously. This avoid shelling out to two processes when one will do. Thus, theoretically, parsing the less files needs to happen only once. As the files are rebuilt, the dependencies will also be updated.

As an example, this is how GCC works.

See the article Auto-Dependency Generation. Particularly the section titled "Combining Compilation and Dependency Generation".

[seven-phases-max]

I think this is basically leads us to https://github.com/less/less.js/issues/2476#issuecomment-76669260.
I dunno if lessc is ever going to replicate the antihuman gcc configurabilty (yet another zillion of zillions lines of code).
So I guess we need to try to reduce the decision just to: "what is more important - the timing of the first lessc run when we do need both (i.e. your case) OR the timing of further runs when no css is often needed (@gtalusan case)".

[de-vri-es]

When considering make, you get the best possible processing time exactly when you produce the dependencies and the output in one run. There simply is no need to generate just the dependencies. Right now I'm forced to process the file twice if I want dependency tracking. And both runs take about the same time.

Maybe there are use cases outside of make where having dependencies without actual output makes sense, but for make #2830 is a big setback.

[seven-phases-max]

Just run lescc w/o --depends first (note the only reason for #2830 was performance, i.e. you still got the same old behavior = lessc-generate-css-only + less-generate-dependencies-only).

So the only drawback is that you need additional:

if (!css-exists)
    generate it;

in your scripts. Well, I guess this is survivable.

---

_{And I still can't imagine a use-case of having the css output before the deps. I.e. if your already got your CSS why do you need its dependencies at all?}

[seven-phases-max]

added "Consider Closing" due to lack of clear use-case description.

[de-vri-es]

The description in #2830 describes that --depends improved performance, with the only downside being that they now ran lessc twice. That was their mistake, they should just generate both the dependency files and the output in a single pass. There is no downside to that, and it avoids running lessc twice.

With the new behaviour, the only way to gain any benefit from --depends is to run lessc twice, which takes twice as long as running it once. That really is not an improvement.

I'm working on a few more improvements to dependency tracking. I'll submit a PR soon.

[de-vri-es]

In case it is not clear: there is no point in having dependency information before the generated output. The dependency tracking makes sure that make only invokes lessc when one of the source files is newer than the output file.

If there is no output file yet, make must always run lessc so there is no value in having the dependency information before the real output.

[seven-phases-max]

@de-vri-es

So the only use of these generated dependencies is to trigger recompilation when they changed?
In that case generating css+deps simultaneosly indeed makes more sense. Then I'm more in favour of reverting #2830 (as there the use-case assumes your dependencies have to be regenerated after the first pass thus the first css output is supposed to be invalid anyway.. Or somtheing like that).

[de-vri-es]

@seven-phases-max: yes, that is what make can use the generated output for.

Note that I submitted #3087, which makes the default behaviour what we had before #2830, but also adds a --no-write flag to suppress regular CSS output. In addition that PR adds -MP, -MT and -MF flags with the same meaning as GCC (and they have friendlier longer names as well).

More info available there.

[de-vri-es]

Also, I guess that there might be use cases outside of make, but the option description does talk about makefiles specifically. In any case, with --no-write it would still be possible to suppress CSS output.

[kevinpeno]

Is this still an issue that needs addressing? If so, what is the expected result for an incoming PR to solve?

[seven-phases-max]

@kevinpeno If I understand it right #3087 had the behaviour we were finally agreed upon - it was not merged just because it forced four or five extra bloatware options.

[kevinpeno]

@seven-phases-max so basically:

1. make --depends output css again
2. add the --no-css option as described
3. Ignore the rest of the additional options

Am I correct in this understanding?

[seven-phases-max]

add the --no-css option as described

Can we invent something w/o adding new options?

[kevinpeno]

@seven-phases-max I can implement it however you like, I was just trying to digest the PR you mentioned into an actionable new PR to help close this issue. If you'd like me to just complete item 1, that's fine. If there's something I'm missing, please elaborate.

[seven-phases-max]

@kevinpeno Since I do not use this options myself, my only wish is to not burden the further maintenance by adding surplus options (then tests, then documentation, then issue reports etc.). So for me something like https://github.com/less/less.js/issues/2925#issuecomment-316849640 would do the trick.
But since it's you going to put efforts please feel free to suggest anything if you feel just reverting #2830 is not enough (well, reverting #2830 as such is impossible as there're too many commits since then so I assume "restoring" pre-#2830 behaviour of course).

[de-vri-es]

I had a need for more flexible dependency tracking again today, so I started this: https://github.com/de-vri-es/lessc-make

Still a work in progress, but it should already work for simple use cases with source maps and dependency tracking. No plugins or other compiler options yet.