cmd-line: Recursive option doesn't work as expected

[egtann]

Tested with node-sass@1.2.3 and @2.0.0-beta, which both seem to have the issue.

Steps to reproduce:

$ npm install -g node-sass
$ node-sass -r app/styles OR ./app/styles OR app/styles/ OR ./app/styles/
> Error: File to read not found or unreadable: app/styles/

$ node-sass app/styles/*.scss
> Works fine

Expected behavior: I should be able to pass in a folder with the recursive option.

Edit: I see now that --recursive is just for watching files. You might consider making it apply to inputs as well, which is the expected behavior from normal cmd-line tools (cp, chmod, etc.).

[kevva]

You might need to use it along with the --watch flag.

[egtann]

Right, but this is part of a package.json build script, so I'm not watching the files.

Watch and recursive should probably be independent options. If not, perhaps the docs/command should be updated to the following?

-w  Watch
-wr  Watch recursively

[kevva]

Nah, but --recursive should definitely work without --watch though.

[egtann]

Also, even with *.scss, it only outputs the first file it finds and saves it as .scss, overwriting the original file. Perhaps this is a different (but serious) issue.

$ ls .
> base.scss       list_item.scss

$ node-sass -r *.scss -o ./
> Rendering Complete, saving .css file...
> Wrote CSS to list_item.scss

Two problems:

1. Notice that it outputs to .scss, overwriting my original file! Good thing I had it in a Vim buffer...
2. It only performs the * match on the first file it finds, and then it exits.

Given the seriousness of the bug (it permanently deletes my un-committed changes without warning), I don't feel comfortable trusting this module in my build script. For now I'm switching back to plain .css.

[am11]

@egtann, for the original issue reported. I would consider as a feature request (to provide recursively compile all files in given directory structure) rather than a bug. :)

I have added it in 2.1 milestone. https://github.com/sass/node-sass/milestones.

The second issue you have reported is fixed. I don't have the exact commit reference handy But this is what I get with the latest build (v2.0.0-beta):

C:\temp1> .\node_modules\.bin\node-sass --version
2.0.0-beta

C:\temp1> .\node_modules\.bin\node-sass -r \temp\foo.scss -o ./
Rendering Complete, saving .css file...
Wrote CSS to foo.css

Also, we do not have glob paths support as well as directory for input file yet. For watch, we certainly do: node-sass#L170.
This will be a nice feature!

This may also effect our watch implementation (#629) as follow:

• Do not allow -w without specifying the input path (be it ./).

This way user would be able to watch any directory and output to any directory, regardless of process.cwd().

Thoughts?

//cc @kevva, @xzyfer

[xzyfer]

To be honest I'm not sure why there is a --recursive option. What's the use case where you wouldn't want recursive watching?

I gut feeling is that this flag is a hold over from the broken watcher implementation pre 2.0.0. With the new smart watcher my vote would be for removing the recursive option and being recursive by default.

[am11]

@xzyfer, do you think retiring --recursive in favor of --no-recursive would make sense?

I believe there are use cases where the user would want to watch-compile or instant-compile (this feature request) only the current directory.

Going by laws of "separation of concern", I also think having a separate no resursive for watch and instant (regular/no-watch) options would make sense (although they are mutually exclusive use-cases: watch-compile & non-watch-compile).

[xzyfer]

I'm unconvinced there's a use case for non recursive watching or
compilation except speed, which is a non issue IMHO.

I consider Ruby Sass as the gold standard here because it covers 5 years of
use cases and user work flows.

I'm not saying if you give people the option they won't use it, but I don't
think anyone needs it.
On 1 Feb 2015 19:50, "Adeel Mujahid" notifications@github.com wrote:

@xzyfer https://github.com/xzyfer, do you think retiring --recursive in
favor of --no-recursive would make sense?

I believe there are use cases where the user would want to watch-compile
or instant-compile (this feature request) only the current directory.

Going by laws of separation of concerns, I also think having a separate no
resursive for watch and instant (regular/no-watch) options would make
sense.

—
Reply to this email directly or view it on GitHub
#601 (comment).

[am11]

@xzyfer, that makes sense. I think we can live without non-recursion if Sassy Ruby say so. :)