Fixed watch behavior

[wesleytodd]

This fixes #781. Using the watch command now finds all of the dependencies and will recompile when one of them changes.

[am11]

After this line, fs.unlinkSync(fixtures('watching/index.css')) and then git rm test/fixtures/watching/index.css to prevent it from bleeding into source-control.

[wesleytodd]

Fixed!

[am11]

Thanks! Can you please rebase into one commit?

[am11]

Please elaborate, what will happen when:

• watch = file.scss and args[0] = file2.scss
• watch = directory/ and args[0] = file2.scss

[wesleytodd]

watch = file.scss and args[0] = file2.scss

This use case is probably the only way you can go wrong with this. This will recompile file2.scss whenever file.scss changes. I cannot imagine anyone wanting that behavior, but that is the way it works now.

watch = directory/ and args[0] = file2.scss

Similarly to the above, this will recompile file2.scss whenever anything in directory/*.{scss,sass} changes.

[wesleytodd]

To be honest this conversation makes we want to change the behavior completely. Seems like --watch should only be a boolean. And arg[0] should only be the files to watch. If you want me to make this PR do that instead I can.

[am11]

Seems like --watch should only be a Boolean

👍 💯

Please go ahead.

As a side note, in case the user has used custom importer option with watch, it will require() that function just once. But while the file is being watched, any change to the importer function would be ignored. To fix this, I think we should unload and re-require the import file before the watcher requests compile-on-change.

Thoughts?

[kevva]

Use multiline var statements.

[wesleytodd]

I had that, but the top of the file was using commas, so I changed it. Are there contribution docs on this stuff that I can read?

[wesleytodd]

@am11 I will do that then. I am not sure what the custom importers do, but I am sure I can figure it out, or if you have docs you can point me to. Otherwise, if I have any questions I will be sure to ask them here.

[am11]

@wesleytodd, you can find the usage in example: https://github.com/sass/node-sass/#examples.
When a user of node-sass set the custom importer, LibSass calls the function as it encounters any Sass @import (as opposed to CSS3 import directive). This way user can alter the file-path and read the data (in case the @import had URL -- because LibSass doesn't download files from URLs -- or even database connection string etc.) and return the altered result to LibSass to continue compilation.

Separately, in this PR, you may be able to address #601 by simply retiring --recursive option and make the default behavior recursive. (-8

[am11]

@wesleytodd, any chance we can wrap this up before v3 stable?

[wesleytodd]

Sorry, been really busy this week. When is the v3 stable deadline?

[am11]

TYT! 😎 👍

Our stable release (v3.0.0) will be aligned with that of libsass v3.2.0. Going by their milestone, https://github.com/sass/libsass/milestones/3.2, we have probably few more days.

I am sorry, but we have included some new CLI features. You would need to rebase. I hope there won't be many merging issues in your feature branch.

Let us know if you need assistance in moving things forward.

[wesleytodd]

Was the cli change anything that effects this feature? The merge was clean but I haven't tested the feature yet.

I will work on getting the new behavior working tomorrow, but if there is anything else I should know about cli changes it would be good to know now :), as I have not been keeping track of the rest of this projects active issues.

[wesleytodd]

Nevermind, rebuilding libsass did the trick. I am not used to working on node projects with c deps.

[wesleytodd]

Whelp.....I made the mistake of getting io setup on my new laptop, and then found this issue: shama/gaze#173

I asked for their recommendation, so if we cannot get node@0.12.x and io.js support we might want to consider going with something similar to this: latentflip/stylizer#6

Thoughts?

[wesleytodd]

So I am no longer sure about that gaze issue. I got it working, I just had a few silly errors that I hadn't noticed in my code. If these tests pass in CI then I think this is ready.

[am11]

Both CI builds are passing. 👍 🎉

Regarding gaze, I saw that issue, but it never failed functioning with io.js et al. on any platform runtime I have used so far. I think it is because the version we are using, v0.5 wasn't relying on C++ module? It is unclear from the history of repo, but going by the code, it seems like it was pure JS module back then. Hence compatibility is not the issue.

Regarding --recursive option, do you think we can live without it, by making recursive a default behavior (and call it a fix for #601)?

[wesleytodd]

I think that it makes sense to keep recursive as an option. There is certainly a situation where you might not want to compile files deeper in the tree. But I do think the recursive option is more common and should be default.

[am11]

I agree with you. So can we can probably just set it here: (https://github.com/wesleytodd/node-sass/blob/bd710c61c76d49cd4decdb59b6a8c68bf07b91b6/bin/node-sass#L86) like this:

..
  precision: 5,
  recursive: true
}

Would you like to fix it in this PR? :)

[wesleytodd]

Updated.

[am11]

Thanks for your contribution @wesleytodd. 🎉

Looks good to me. 👍

[wesleytodd]

@am11 Glad I could help!! Its a good project, so I am sure I will be using it a lot. Maybe find some more time to help out in the future.

[am11]

Maybe find some more time to help out in the future.

Most welcome and keep coming back! 😎 👍

[am11]

Few things I noticed:

• With meow package, the CLI arguments parser, converts all non-true values to false. Meaning:
  • node-sass blah.scss --watch --recursive false == node-sass blah.scss --watch --recursive untrue == node-sass blah.scss --watch --recursive foo
  • while node-sass blah.scss --watch --recursive true == node-sass blah.scss --watch --recursive == node-sass blah.scss --watch
• You are the 100th contributor to this project, so here you go: 💯 🏆 😃

[wesleytodd]

@am11 I believe that is the behavior from minimist. This is a very commonly used package, so my guess is this behavior is fine, despite it's oddities. We could submit an issue over there if you have a better suggestion for these behaviors.

Yeah me! Thanks for the 🏆!

[wesleytodd]

Also, while pursuing the minimist source I noticed it supports --no-recursive.

And here is the issue in minimist for reference: https://github.com/substack/minimist/blob/master/index.js#L158

[am11]

I agree that --no-recursive would be better suited here, when recursive is a default behavior.