Skip to content
This repository has been archived by the owner on Jul 24, 2024. It is now read-only.

Exposing watch in API #1056

Open
baileyparker opened this issue Aug 7, 2015 · 12 comments
Open

Exposing watch in API #1056

baileyparker opened this issue Aug 7, 2015 · 12 comments

Comments

@baileyparker
Copy link

I've read through the issues about the --watch flag and appreciate the amount of effort that has been put into maintaining it! 😄 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
Copy link

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
Copy link
Member

saper commented Aug 7, 2015

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

@schmod
Copy link

schmod commented Aug 11, 2015

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

@monarchwadia
Copy link

+1 would like this functionality.

@niksy
Copy link

niksy commented Jan 20, 2016

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

@DarkPark
Copy link

+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
Copy link

@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
Copy link
Member

saper commented Feb 14, 2016

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 #1288 #1261 #1260 #1216.

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

@cguinnup
Copy link

cguinnup commented Jan 19, 2017

+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
Copy link
Member

saper commented Oct 18, 2019

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

@saper saper added this to Backlog in Dependency tree management Oct 18, 2019
@nex3
Copy link
Contributor

nex3 commented Feb 11, 2020

FYI sass/sass#2823 now exists to discuss this in a cross-implementation context.

@ymatuhin
Copy link

+1

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

No branches or pull requests