Skip to content

Excessively restrictive requirements on source layout #25

@deadmoose

Description

@deadmoose

These checks look for the rightmost location of specific directory names (content, static, etc), requiring the actual source repository have directories named that, despite the fact that the files are copied to a secondary location.

In addition, the implementation of that check requires that the directory (e.g. content) must have a slash preceding the prescribed name, so you cannot have them at the very top of the workspace.

https://github.com/deadmoose/hugo_rules_content_demo demonstrates some potential layouts:

  • top_level shows the content directory at the very top & fails: failed to get relative path: couldn't find content in content/_index.md
  • anything_else doesn't call it content, and thus fails: failed to get relative path: couldn't find content in foo/bar/_index.md
  • down_one works because the content directory is foo/content so it's internally calling relative_path('foo/content/_index.md', 'content')
  • double_content shows a situation where someone happens to name a directory within their site content. Since the rightmost occurrence of /content/ is treated as special, both foo/content/_index.md and foo/content/foo/content/_index.md try to generate the same output file & it chokes.

I've got full sympathies for how painful it is to do complex transforms from your source layout to something else, but the silent misbehavior if anyone happens to use one of the fairly common reserved words (content, static, images, layouts, data, assets, i18n) is pretty dangerous, and failing on a workspace-root version of one of those is extremely confusing when onboarding.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions