Chokidar: Symlinks not followed

[jwahlin]

Symlinked files are not followed, even with followSymlinks explicitly set to true.

You may use the following code to replicate the problem:

const chokidar = require('chokidar');

var watchFiles = [
  "path/to/non-symlinked/file",
  "path/to/symlinked/file",
]
var watcher = chokidar.watch(watchFiles, {
  ignored: /(^|[\/\\])\../,
  persistent: true,
  followSymlinks: true
});

// Something to use when events are received.
var log = console.log.bind(console);

// Add event listeners.
watcher
  .on('add', path => log(`File ${path} has been added`))
  .on('change', path => log(`File ${path} has been changed`))
  .on('unlink', path => log(`File ${path} has been removed`));

When I make a change to the non-symlinked file, I get a console message that the file has been changed. When I make a change to the symlinked file, no event bubbling occurs and no console message appears. If I adjust the symlink itself, then event bubbling does occur.

This issue is significant to my team because we are using Bazel to build all of our projects. Bazel runs the development server in a sandbox where it creates symlinks to all of the files in our app.

My environment
| Software | Version(s) |
| ---------------- | ---------- |
| Chokidar | 2.0.2
| Node | 9.7.1
| npm/Yarn | 5.6.0
| Operating System | High Sierra

[JRileyH]

Any resolution on this issue? I am attempting something similar and experiencing issues.

[Globegitter]

We are running into the same issue (also using Bazel) on macOS only, I had a bit of a play around with it and seemed to be able to fix it. It is pushed here: https://github.com/ecosia/chokidar/tree/symlink-fix-mac It was kind of a blind fix to be honest so not sure if it might break other things - tests do seem to be passing fine for me though (well I have 8 failing but also have 9 failing on master on my Mac)

[athoscouto]

Any contributor can give any insight on this? Also facing the same problem.
@Globegitter changes seems to have fixed the issue, but I don't feel comfortable using a fork. Any change we can turn it into a PR?

Edit: it seems the issue was fixed on 2.0.4. False positive

[Globegitter]

@athoscouto Agreed, I would also feel much more comfortable if we could apply a fix to master but if it makes you feel any better we have developers internally using this on a daily basis without any issues so far

[paulmillr]

I think what happens here is that the initial symlink path is getting ignored (initial as in ln -s initial target). What happened in this pull request is that you've made target to be ignorable by ignored: option. I don't think that's how we want it to work.

So, to everyone else: ensure your paths don't match ignored filterer. Otherwise, feel free to comment and we'll reopen this.

[Globegitter]

@paulmillr It sounds very right that my PR "fixed" the issue incorrectly, but how come macOS and Linux behave differently with the same config?

But you are saying if we change the ignored in the example provided by the issue author it should also work on macOS?

[Globegitter]

But also seeing that 3.x has been released so will also give that a try.