no idea about why Jekyll is doing that but you could use Gulp and browsersync and get live reloading, and part of that would be better control of what triggers the rebuild. I use Gulp to do the watch part, then it triggers Jekyll build.
cons: I think it is a little slower, can be complicated to set up if you are not familiar with it.
I guess something is wrong with your configuration. Here is my experiment with a setup similar to yours but using jekyll serve --verbose to peek behind the scenes.
And if I change anything in __vendor or _vendor Jekyll (jekyll-watchactually) does ignore any changes in these locations as expected…
Ok - it’s probably something with the simlinks, which I didn’t fully describe in my example. Maybe for efficiency the watch process watches the parent dir or something, which could explain it. Thanks for your help. I’ll close it since you’re right - it’s probably on my end.
Happy to help! Oh, I did miss the part about symlinks - let me try the other experiment with symlinks. My gut feeling is that since symlinks underneath __vendor folder, they should be ignored as well but we will see…
Can you also share the script you used to create symlink?
UPD: I did setup just like yours is and can repro the very same error in the console 100%. Just like in your configuration, I created vendor/dir1 and vendor/dir2 (symlink to dir1):
I dig further thru the codebase of jekyll-watch and listen gems and here is what I have found. The reason why the error message appears is because one of the listen gem components, record.rb, in _fast_build_dir method, indexing all the children items without taking into account the exclusion list and therefore prints out the error message.
Good news however, locations configured in _config.yml actually are excluded from the list of those being watched despite of the error. So, it is not a critical error per se - your Jekyll instance should remain fully functional.
The error message however a bit annoying and very confusing. I guess I have a clue how to fix it in the original code base…
UPD: Have forked the repository of listen gem (this is what jekyll-watch uses) and added some tests for your case to catch the gem red-handed of not handling the case properly… Believe it or not, the behavior is not triggered…
I’m still trying to wrap my head around how the gem is doing its work and doesn’t trigger the error code path.
Will try again on the weekend as the time permits…
Phew, have got some good progress and have found a solution to the issue, though the glitch still has to be fixed in the source code to make it bulletproof.
Here is the way how it DOES work (eq. way you can solve the issue). First, you need to setup a symbolic link between folder vendor/a and vendor/b using ln -s command and this is the visual log of how that would look like (TERMINAL tab):
Notice where b link points to… /Users/pabloduo/Documents/Github/avocado/docs/vendor/a, this is a fully-qualified path to the source folder. And if you launch bundle exec jekyll serve --verbose with this setup - you should see no error message in the output… This is how it looks like:
Now, there is another interesting part of the issue… How would you reproduce the problem? It turns out there is a slight, but very important nuisance - path to your source directory when you create a symbolic link
Lets re-create linked folders structure again, this time NOT using fully-qualified path the source folder, like this:
The summary is, for now use fully-qualified symbolic links between ignored folders in Jekyll and in the meantime I will try to send a pull request to listen gem to address the issue in full.
