Add command line switch to print dependencies

There are situations, where one is interested only in dependencies for a specific Sass file, e.g., in Makefiles. It would be great, if Sass could provide such a list. For example:

// file foo.scss
@import "bar";

// file _bar.scss
@import "baz";

// file _baz.scss
// ...some Sass...

Then imagine this call and response:

$ sass --print-dependencies foo.scss
_bar.scss
_baz.scss

It would be great to have for auto-generating dependency files for your build tool of choice, e.g. GNU make:

$ echo "foo.scss: $(sass --print-dependencies foo.scss)" > foo.scss.mk

[chriseppstein]

Printing dependencies is not an aspect of compiling Sass files.

As demonstrated, it is an aspect of integrating with a build tool for compiling sass files. gcc provides this ability via the -M command line option. From the man page for gcc, the -M option: “Instead of outputting the result of preprocessing, output a rule suitable for make describing the dependencies of the main source file.”

Emitting the same output we normally do in a machine-readable format is different

Newline separated lists is a very machine readable format designed for use with numerous unix utilities. For example: sass --dependencies foo.scss | xargs vim and now I’ve opened every dependency of my file in my text editor. It also works great with grep.

You can even make a fair go at invoking it from the command line

That’s not a fair go at it. It doesn’t take import paths into account. It doesn’t take relative imports into account. Doing these things correctly is non-trivial.

The issue isn’t that sass shouldn’t integrate with other tools; it’s that listing dependencies is outside its purview.

The claim is that listing dependencies is a form of tool integration. A code example was provided by @codifferous showing this to be true. Simply stating that the purview of sass is one form of tool integration but not another is not founded in a rational basis. You have made a value judgement that one tool is more important to integrate with than another and that the first one is worth working on and the second one is not.

this is a narrower use-case than warrants the cost of adding a new option.

This is really the core of your argument. You simply don’t think it’s worth supporting make out of the box. I disagree. Make continues to be an important build tool and I don’t find the cost of having this option in the -h output onerous. But, to be fair, GCC doesn’t list the -M option in the --help output, it only mentions it in the man page.

It doesn’t make sense to add every option that would be useful to anyone.

Every option should be evaluated independently. I’ve certainly rejected many of them. No one has claimed that every option should be added, and using a slippery-slope argument is not productive.

[nex3]

This is not planned.