Do not watch directories with no mounted files in it

[trapperhoney]

What version of Hugo are you using (hugo version)?

$ hugo version

v0.135.0+extended

Does this issue reproduce with the latest release?

Yes

Issue

In trying to migrate an existing site to Hugo, I believe I found a bug in the file watcher of the built-in test server.

Direct migration involves a directory structure that does not match the default Hugo directory structure. In particular, content is hosted in the root directory (and subdirectories) while metadata and configuration are stored in a specially named subdirectory under the root, which I'll name hugo in this example. The following tree describes this structure and is sufficient to reproduce this issue:

root/
├── hugo/
│   ├── hugo.toml
│   ├── layouts/  <- minimal for completeness/avoiding warnings
│   └── public/
├── dir1/
│   └── post1.md
├── dir2/
│   └── post2.md
└── index.md

This directory structure can be configured with the mounts module in a minimal hugo.toml file:

title = 'Some Title'

[module]
  [[module.mounts]]
    target = 'content'
    source = '..'
    excludeFiles = 'hugo/**'

When building the site from within the hugo directory, everything works as expected. There are no warnings/errors and the public directory is fully populated with the expected content. However, when using the hugo server command, the process will sometimes bring up the server after many errors, sometimes hang, and sometimes crash. The example output included at the end of this issue seems to imply that the file watcher notices as output is added to the output directory and triggers continuous rebuilds.

I believe that the excludeFiles option for the mounts module works correctly for excluding content from the content-building system, but does not exclude files from the file watcher in the built-in test server.

Workarounds

Including disableWatch = true in the mount definition fixes this issue at the expense of disabling automatic rebuilds while the server is running.

Alternatively, including a top-level option of ignoreFiles = ['/hugo/.*$'] seems to fix this issue with configuration redundancy being the only downside. This is a perfectly acceptable workaround for my situation, but I thought I should raise this issue as the include/exclude options in the mounts module seem to be preferred over the global ignoreFiles option in the project's documentation.

Example output (hugo server)

Watching for changes in /tmp/root/{dir1,dir2,hugo}
Watching for config changes in /tmp/root/hugo/hugo.toml
Start building sites …
hugo v0.135.0+extended linux/amd64 BuildDate=unknown

                   | EN
-------------------+---
  Pages            |  9
  Paginator pages  |  0
  Non-page files   |  0
  Static files     |  0
  Processed images |  0
  Aliases          |  0
  Cleaned          |  0

Built in 7 ms
Environment: "development"
Serving pages from disk
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at //localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop
adding created directory to watchlist /tmp/root/hugo/public
adding created directory to watchlist /tmp/root/hugo/public/tags
adding created directory to watchlist /tmp/root/hugo/public/categories

Change detected, rebuilding site (#1).
Source changed /hugo/public/categories/index.html
Source changed /hugo/public/categories/index.xml
Source changed /hugo/public/index.html
Source changed /hugo/public/index.xml
Source changed /hugo/public/sitemap.xml
Source changed /hugo/public/tags/index.html
Source changed /hugo/public/tags/index.xml
Web Server is available at //localhost:1313/ (bind address 127.0.0.1)
Total in 5 ms

Change detected, rebuilding site (#2).
Source changed /hugo/public/categories/index.html
Source changed /hugo/public/categories/index.xml
Source changed /hugo/public/tags/index.html
Source changed /hugo/public/tags/index.xml
Web Server is available at //localhost:1313/ (bind address 127.0.0.1)
Total in 2 ms

This particular invocation never terminated.

[bep]

I guess this somehow relates to ... #12918

One workaround you don't mention is to ... move the directories to a more ... traditional setup.

[bep]

OK, looking at fcdc454cc58e9f26ba29389100adfc09cb383448 -- that doesn't actually solve this particular issue.