Unusual directory structure

support
1

Hi,
I’ve been playing with a new site and wanted to have a slightly different directory structure, specifically to prioritize the content.

I ended up with the content in the root of the repo, with a .hugo directory and a .build directory.

/_index.md
/about.md
/blog/...
/.hugo/config.yaml
/.hugo/{archetypes,assets,data,i18n,layouts}
/.build/{public,resources}

I happen to run Hugo via Docker, so I have a /.hugo/docker-compose.yaml, which is using klakegg/hugo:0.72.0-alpine.

My config.yaml looks like

baseURL: "/"
languageCode: "en-us"
title: "example.com"

#permalinks:
#  post: "/post/:year/:month/:day/:slug/"

# generated artifacts are in .build
publishDir: .build/public
resourceDir: .build/resources

ignoreFiles:
  - .hugo/
  - .build/

module:
  mounts:
    # actual content is in the repo root
    - source: .
      target: content

    # hugo "stuff"
    - source: .hugo/archetypes
      target: archetypes
    - source: .hugo/layouts
      target: layouts

    # somewhat content-like, but not needed just yet
    - source: .hugo/data
      target: data
    - source: .hugo/assets
      target: assets
    - source: .hugo/i18n
      target: i18n
    - source: .hugo/static
      target: static

I’ve noticed that without the ignoreFiles configuration, if I edit a layout template in /.hugo/layouts/_default then I get an error

ERROR 2020/06/18 11:57:24 Rebuild failed:

ERROR 2020/06/18 11:57:24 "/src/.hugo/layouts/_default/list.html:1:1": unmarshal failed: invalid character '{' looking for beginning of object key string

It basically doesn’t matter what the edit is, or seemingly where it is, but editing a file in the /.hugo directory triggers this error. More editing of files doesn’t resolve it. Restarting hugo server does resolve it.

Adding the ignoreFiles configuration stops the error, but now hugo doesn’t regenerate if templates are edited within the /.hugo directory.

My understanding is that ignoreFiles is meant to ignore files only for content. There’s some long standing ticket related to this and static files, so I’m surprised that this seems to stop detection of modification of templates.

I realize I’m probably doing something a little unexpected, but in this scenario I am hoping to be able to keep content forefront