Fix hot reloading for config.toml
in zola serve
on Linux
#2498
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introduction
Fixes #2266 , alternative to #2269 which appears to be stalled and has a large diff against
next
. In particular, this fixes hot reloading for changes made toconfig.toml
via the caching strategy used by editors such as vim on Linux. At the time of this writing, changes written toconfig.toml
via at least vim and neovim on Linux are not noticed at all byzola serve
.Code changes
config.toml
's containing folder--notconfig.toml
directly--for changes. See Details for why.config.toml
, assuming that all other files we care about are nested more deeply than the config file. This is the case at the time of this writing, and the Zola docs suggest thatconfig.toml
is the only top-level file we watch in a zola project.config.toml
.Details
Editors such as vi, vim, and neovim cache changes to swap files. When a user wants to write to the original file, such editors may delete the original file and replace it with the swap file. This changes the inode of the "original" file. The file-watching strategy on Linux is inotify which watches for changes via inodes, not file names. So when an editor like vim deletes the file we're watching, we lose event information on that file after the final delete event. If we instead watch the owning directory, we can observe events on all file changes and with some filtering pretend like we're watching the same
config.toml
file all along.The reason this bug is not observed on macOS is because macOS uses FSEvents to watch for file system changes. FSEvents monitors on the directory level. The change here makes behavior on Linux approximate that of FSEvents.
zola uses Notify v4, and
notify::watcher
returns aRecommendedWatcher
. The recommended watcher on macOS isFsEventWatcher
whereas it isINotifyWatcher
on Linux.Testing
Due to where the ignore logic is done in
serve.rs:serve
, we can't really extend the tests in the same module to check this feature.I have manually checked
zola serve
on Linux and macOS by editingconfig.toml
and theme files and observing hot reloading. I also editedtheme.toml
at the top-level of a zola project, and such changes were correctly ignored.I don't have a Windows platform to test on.
UI
Due to the watch list remapping,
zola serve
still announces the following to the end user (noteconfig.toml
even though we watch the parent directory).