--watch is flaky

[EmilyChews]

Hi,

I got a new Mac recently so I thought I would use this as a reason to move from Ruby Sass to Dart Sass.

The installation was all OK and it works in my projects, but I'm having an issue where after a certain number of SCSS changes (circa 20 or so) Sass stops working.

The work around I have is just stopping the watch (ctrl + c) restarting it and then making a change to the file so it compiles.

I never had this problem on Ruby Sass, so I wiped and re-installed Dart Sass, but it's still happening.

I do have my editor (VS Code) set to auto-save, but as mentioned above the issue wasn't happening with Ruby Sass and I used auto-save in that version as well.

Has anyone else had this issue / and or know how to fix it, instead of constantly having to stop the watch and re-compile?

Many thanks

[nex3]

How did you install Sass? What version are you using? Are you working on a local drive or a network drive of some kind? Does this still happen if you pass --poll?

[EmilyChews]

Hi

I installed it with Homebrew and did brew install sass/sass/sass via the command line on a local drive (MacBook). When you say pass poll - what does that mean?

[nex3]

I mean pass --poll it as a command line option to the Sass executable when you invoke it.

[EmilyChews]

Hi nex3,

Sorry for the delay, I was away over Xmas.

I did the following:

sass --watch scss:./ --style compressed --poll

That didn't make a difference, and I'm still having the same issue :(

It's really starting to affect / slow down my workflow and I don't know what to do?

[nex3]

I still need some information from you: what version of Sass are you using? Are you on a network drive of some kind? What exact error does Sass print when it stops working?

[h2obuffalo]

Hi nex3
I am also having the same problem (as are a number of other people in my class).
All running OSX 10.14 on various different macbook pro's/Imac's -
I'm running Sass v1.16.0 compiled with dart2js 2.1.0
Working with files on local drive.
No error is printed in the terminal, it just stops compiling, ctrl c and restart watch fixes it but defeats the point of the watch function.
Only just being introduced to the world of SASS so would love to get it working so I can put it to use properly.
Many thanks

[nex3]

@h2obuffalo Does --poll work for you?

[h2obuffalo]

I have switched to the old ruby version as needed it to work whilst doing the introductory lessons to SASS (only have the classes this week). I'll go back to the dart version when I'm using it in the future.

Also just to add, with --watch on. It still said it was compiling successfully in terminal on each save, but the changes were not in the outputted css file.

[EmilyChews]

@h2obuffalo Can I ask if you have autosave turned on in your code editor?

[h2obuffalo]

@emilyChewsCheese I have never had autosave turned on, no.
Just manually saved each time I made a change I wanted to see in the browser.

[vincedubroeucq]

Hi,
I'm having the same problem. The watcher runs, says everything is compiled correctly after each save, but changes are not reflected in the browser.
I'm using dat-sass 1.16.1, installed normally, and using standard watch command.
--poll doesn't make any difference.

[nex3]

@vincedubroeucq You say the changes aren't reflected in the browser... do you see the changes in your CSS files on the filesystem?

[vincedubroeucq]

Oh, I'm sorry I wasn't clear here. They are not always reflected in the styles file. It is not systematic, though. Sometimes the watcher works just fine, sometimes changes are not reflected in the .css file, so I have to stop the watcher and restart it.

[nex3]

Since people are continuing to report this: since I can't reproduce this issue, there's not much I can do to fix it myself. If someone who can consistently reproduce it is willing to dive into the Dart Sass codebase and try to debug the issue themselves, that would be a huge help.

[Llbe]

I can reproduce this. Unfortunately I'm not familiar with the source of Dart sass, nor of Dart but if I find more time I will try to debug this further. Please ask any questions.

• I run Linux 4.18 / Ubuntu 18.04

• Sass 1.18.0

• Dart 2.2.0

How I'm testing

• In my /home directory, I mkdir -p src/foo then I create three files: foo.css, foo.scss, _bar.scss

• foo.scss:

  @import '_bar';
  
  #foo
    {
      background:#aaa;
    }

• _bar.scss

  #bar
    {
      background:#bbb;
    }

• To run sass I do rm src/foo/*map ; env -i /usr/local/bin/sass --no-poll --watch src/foo:src/foo alternatively with --poll

  Note that I remove any source map and that I run with no environment.

• Then I add/remove the line with #bbb background. When it works, the foo.css results with both #aaa and #bbb backgrounds as expected and when it doesn't work it only contains #aaa background

• When it stops working, Sass prints that foo.css was compiled but no changes are reflected, neither if foo.scss or _bar.scss are written

• I cannot reproduce this with a simple case without the @import

• --poll works and --no-poll doesn't work. However I'm not entirely sure that this is a core difference of the issue. Before trying to isolate this further I believe I had issues with --poll as well but I cannot reproduce it reliably. With the setup above I can reproduce the issue with --no-poll at 100% of my attempts

• FWIW, I recently upgraded from 1.15.0 (to 1.18.0). I didn't experience this before the upgrade

• If anyone wants, I can attach a strace output of Sass. Or any other info that would help

[Llbe]

Related to #573?

[nex3]

@Llbe Even following those instructions, I'm totally unable to reproduce this. If you'd like to debug further (which I encourage you to do—Dart is a very straightforward language), the logic for --watch lives in this file and calls out to this class.

It's also possible that the problem is at a lower level. The key libraries we call out to are StreamGroup from the async package, which we use to merge streams of events from multiple directories into one single stream; and (for your OS) LinuxDirectoryWatcher from the watcher package, which wraps Dart's built-in FileSystemEntity.watch() function to make it more normal and reliable across different operating systems.

If you want to dive into one of these packages' code to add debugging statements (for example to figure out whether the watcher package is even receiving events from the OS), you can check it out from GitHub, add

dependency_overrides:
  watcher: {path: /path/to/watcher/checkout}

to the pubspec.yaml, and run pub get. This will load the code from your checkout on disk.

[EmilyChews]

I'm still at a loss as to why they ever moved Sass over from Ruby. Everything worked wonderfully in the old version. Emily.

…

On Fri, Apr 26, 2019 at 12:05 AM Natalie Weizenbaum < ***@***.***> wrote: @Llbe <https://github.com/Llbe> Even following those instructions, I'm totally unable to reproduce this. If you'd like to debug further (which I encourage you to do—Dart is a very straightforward language), the logic for --watch lives in this file <https://github.com/sass/dart-sass/blob/master/lib/src/executable/watch.dart> and calls out to this class <https://github.com/sass/dart-sass/blob/master/lib/src/util/multi_dir_watcher.dart> . It's also possible that the problem is at a lower level. The key libraries we call out to are StreamGroup <https://github.com/dart-lang/async/blob/master/lib/src/stream_group.dart> from the async package <https://pub.dartlang.org/packages/async>, which we use to merge streams of events from multiple directories into one single stream; and (for your OS) LinuxDirectoryWatcher <https://github.com/dart-lang/watcher/blob/master/lib/src/directory_watcher/linux.dart> from the watcher package <https://pub.dartlang.org/packages/watcher>, which wraps Dart's built-in FileSystemEntity.watch() <https://api.dartlang.org/stable/2.2.0/dart-io/FileSystemEntity/watch.html> function to make it more normal and reliable across different operating systems. If you want to dive into one of these packages' code to add debugging statements (for example to figure out whether the watcher package is even receiving events from the OS), you can check it out from GitHub, add dependency_overrides: watcher: {path: /path/to/watcher/checkout} to the pubspec.yaml, and run pub get. This will load the code from your checkout on disk. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#550 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFNTBH5W242GHEIMJLRARKDPSI2KNANCNFSM4GK5HXAA> .

[nex3]

I'm still at a loss as to why they ever moved Sass over from Ruby.

This isn't really the place to talk about that, but we've written about the reasons for migrating in the Dart Sass announcement post and in this package's README.

Everything worked wonderfully in the old version.

That's not really true. Ruby Sass also had many many difficult issues relating to filesystem watching.

[Llbe]

@nex3: thank you for the pointers. I've only looked a bit yet but I agree that the issue probably is at a lower level.

In the meanwhile I wrote a quick Bash script to watch and compile files without --watch. It also handles @import recursively. However I'm sure there are a lot of issues with this approach, I only did it for a specific project to avoid issues there. Just figured someone might benefit.

https://gist.github.com/Llbe/3eed046d7737654887dc7870de81de03

Edit: now it compiles in parallel.

[Rumyra]

I wanted to comment:

I teach in a class and we've been using the watch functionality with dart for the past 6 months or so

This past week I noticed something I hadn't noticed before because of my assumptions and this thread... it actually happened with ruby sass as well (I had a student on an old machine for reasons)

Now this could be purely coincidental, but I wanted to note it. Sorry I don't have more info - I've been trying to find some consistency for a while now and I haven't - I will keep trying

[bostiq]

Hi... I can't find anywhere else to go for support on this.
(not experience programmer here...I do however intense css writing)

I too thought to migrate from ruby to Dart sass but for the moment is unusable to me. I'm on Mac Os X

Not knowing if the ruby version would interfere I uninstalled it first with gem uninstall,
then installed with the new dart version with brew install sass/sass/sass

I went to test it and it comes up with all sorts of parsing issues:
the command I used was sass --watch style.sass darS.css and after reading this thread is sass --watch style.sass darS.css --poll

example 1 - Note! this is from a mixin file and the line was in a comment! and the highlighted red error was the $type part

Sass is watching for changes. Press Ctrl-C to stop. Error: Undefined variable.

36 │ // filter: progid:DXImageTransform.Microsoft.gradient(GradientType="#{$type}",StartColorStr="#{$step1}", EndColorStr="#{$step2}")

_mixin.sass 36:73 @import
style.sass 3:9 root stylesheet

Example 2 - Note! again this is from a mixin file and the highlighted red error was the /* part of the inline comment - it did resolve if I put this comments on a new line
Error: Expected expression.
33 │ background-color: $step1 /* Fallback Color*/

_mixin.sass 33:29 @import
style.sass 3:9 root stylesheet

So this is good:
background-color: $gradient1
/* Fallback Color */

But this is not
background-color: $gradient1 /* Fallback Color */

Is this behavior normal? the issue is that although I can fix all my inline comments relatively easily, I'm baffled by 3 things:

1. This outputs an error on $type :
   filter: progid:DXImageTransform.Microsoft.gradient(GradientType=#{$type},StartColorStr=#{$step1}, EndColorStr=#{$step2})

2. sass trying to parse the above, giving me the same error, even when I dev comment // the line

3. On deleting the whole line altogether and saving, the terminal outputs the same error again as if the line still there... eventually, after restarting the sass --watch style.sass darS.css --poll and pressing command-S the parser will go to the next filter: progid: ... line where it will highlight an interpolated variable again

however is exclude the _mixin.sass and delete the lines where the style.sass refer to them, everything else seem to go fine.

Sorry for the long spill but I wanted to be as detailed as possible about my findings.

[nex3]

@bostiq This is a great question for the Sass StackOverflow community! We try to keep this issue tracker focused on bugs and feature requests that need the core team's attention in particular, while requests for support are usually better handled by the community at large.

[pxninja]

I stumbled across this issue after experiencing the same. In case my experience is of any use (or to affirm other experiences):

1. I'll use sass --no-source-map --watch src/scss:dist
2. It will work as expected for a while, after which the terminal will indicate "Compiled", though the output has not been updated
3. This will consistently happen after a compile error
4. What's really odd: if I delete the output css and save a change in the scss, the terminal will indicate "Compiled", a new css outputs ... but it's the old code (not the revised code)
5. If I Ctrl-C and then sass --no-source-map --watch src/scss:dist again, it will work as expected, until it doesn't

---

Answering some of the previous questions, if it's useful:

• Installed with brew install sass/sass/sass
• Version 1.23.3
• Working on local drive
• I have not tried --poll
• A variety of errors will produce this, the most recent being Error: expected "}". Once I fix the error, the terminal will indicate "Compiled", but the actual file does not change, as noted above.
• Similar to this comment, I use @import to reference other files like _buttons.scss.
• Mac OS (10.13.6)

[elgandoz]

I'm experiencing the exact same issues as described by @pxninja. I also tried the --poll flag with no difference.
As him, I can work normally for a while, until at some point the reported behavior will start to show consistently.
I need to purposely generate an error in order to re-trigger a working compile, otherwise I will get a Successful message, but without a real compile.
I'm on RHEL 7, sass 1.22.12.

[Majasi]

I'm having exactly the same behaviour as @pxninja, also installed via homebrew, I'm running MacOS Catalina and editing locally on a local drive. The changes are detected but the compiled css file does not reflect the changes.

[Rumyra]

I have some ideas... how many of you are running local servers when you're using the --watch functionality?

[edgars-vasiljevs]

@nex3 I believe the issue is in _Watcher class. Once it encounters syntax error in imported (via @import) sass file, it removes invalid file (node) from stylesheet graph and never adds it back.

You can replicate it by creating following files:

// style.scss
@import "test";

// test.scss
body {
    background: #000;
}

• Run sass with --watch flag, compile style.scss file.
• Remove curly bracket to force syntax error, save the file
• Fix syntax and update background color to #fff, save the file.
• Background stays as #000 in compiled css.

I'm no expert in Dart but this what I think is happening:
_Watcher calls _handleModify when it sees test.scss being modified which in turn calls _graph.reload. When _graph.reload sees invalid file, it removes it from stylesheet graph. Later when we fix syntax and save file again, same _handleModify method is called again, but this time is tries to add missing file using _handleAdd. But it doesn't seem to work.. it never gets added. Not sure why.

I managed to fix it by reloading changed nodes inside _retryPotentialImports. See my commit.
It forces parent node (style.scss) to reload upstream nodes. It's probably not the best solution but works well for me.

Hope this helps.

[nex3]

Major thanks to @edgars-vasiljevs—that information finally proved to be enough for me to reproduce the bug, which should be fixed in the upcoming 1.26.1 release.

[MattrCoUk]

I just noticed it in dart2js 2.14.4.
Seems to be occurring for deeply nested @imports. (Windows 10, Node v17.1.0)
Is there a workaround? I remember from ol Ruby Sass something like sass cache clear...

Interestingly, when I mount the drive from mentioned Windows 10 machine onto a Mac and run same 'sass --watch’ from command there, it registers the changes correctly (just painfully slow).

[nex3]

If it's working on some operating systems but not on others, it's likely to be an issue either with the underlying operating system's file-watch logic or with the chokidar package we use to access file-change events.