Exposing watch in API

[baileyparker]

I've read through the issues about the --watch flag and appreciate the amount of effort that has been put into maintaining it! :smile: The implementation is impressively terse and as I understand it (the PR mentioning this was merged), has recently been overhauled.

Would it be possible to expose this in the Node API so that it could be invoked programmatically (from a task runner like Gulp or Grunt, or just in plain Node) through something like sass.watch('./file.scss')?

In the case of task runners, this could allow allow for an evented API that allows for additional build steps on recompile. Perhaps something like this:

var sass = require('node-sass');

sass.watch('./file.scss')
  .on('update', function(file) {  // where file is a Vinyl instance
    // Version image url() assets, for example
    file.contents = cssVersioner(file.contents);
  });

If this sounds reasonable, I could get started on a PR for it. Otherwise, I plan on creating a npm module for this.

[SpaceK33z]

I would also like a way to use the watch functionality through an API. This has the big advantage that external build tools are not necessary if you want to have a callback when a file is compiled.

[saper]

I think we should expose this. Maybe one day we will be able to tell libsass which files need to be reloaded individually.

[schmod]

Agree, and I'd be willing to add hooks into grunt-sass once this is done.

[monarchwadia]

+1 would like this functionality.

[niksy]

Any progress on this? It would be really nice to have this as part of Gulp/Grunt process.

[DarkPark]

+1

a good example of implementation is webpack:

var webpack = require("webpack");

// returns a Compiler instance
var compiler = webpack({
    // configuration
});

// regular build
compiler.run(function(err, stats) {
    // ...
});

// build + watch
compiler.watch({ // watch options:
    aggregateTimeout: 300, // wait so long for more changes
    poll: true // use polling instead of native watchers
    // pass a number to set the polling interval
}, function(err, stats) {
    // ...
});

[genintho]

@saper I would like to try to tackle this issue. Do you have any advice on how to do it? I tried to look at the way render works, but it seems that the way it works in the cli and the way it is done in lib/index.js is totally different. I would like to try to avoid duplicating the grapher/gaze configuration.

Thanks.

[saper]

There is a proposal in #1156 to split CLI as the separate module and I think this is a good way to fix our hopelessly broken command line interface (in a incompatibly way I hope).

This way CLI could depend on the watcher (whichever one is about to be chosen) and the dependency calculator (currently https://github.com/xzyfer/sass-graph).

For now we have disabled CLI watcher tests, because they were not working. Maybe trying to expose the API and use that in tests would be a good place to start. See https://github.com/sass/node-sass/pull/1288 https://github.com/sass/node-sass/pull/1261 https://github.com/sass/node-sass/pull/1260 https://github.com/sass/node-sass/pull/1216.

Calling a watcher is actually a line or two in our CLI so it might be not that difficult.

[cguinnup]

+1 Looking for a way to watch a file and its @imports (which are from multiple directories). The CLI allows watch, but only the API allows multiple @import dirs.

[saper]

lib/watcher.js is already a progress, but the way it is called from node-sass binary needs to be refactored

[nex3]

FYI https://github.com/sass/sass/issues/2823 now exists to discuss this in a cross-implementation context.

[ymatuhin]

+1