create: Use archetype template as-is as a Go template

[bep]

This commit removes the fragile front matter decoding, and takes the provided archetype file as-is and processes it as a template.

This also means that we no longer will attempt to fill in default values for title and date.

The upside is that it is now easy to create these values in a dynamic way:

+++
title = {{ .Name | title }}
date = {{ .Date }}
draft = true
+++

You can currently use all of Hugo's template funcs, but the data context is currently very shallow:

• .Type gives the archetype kind provided
• .Name gives the target file name without extension.
• .Path gives the target file name
• .Date gives the current time as RFC3339 formatted string

The above will probably be extended in #1629.

Fixes #452
Updates #1629

[digitalcraftsman]

I agree that the implementation looks much cleaner now 👍

You can currently use all of Hugo's template funcs, but the data context is currently very shallow:

I would like to propose to extend the list as follows:

• users should have access to a subset of data available from the config file:
  • .Site.Author
  • .Site.BaseURL
  • .Site.BuildDrafts
  • .Site.Data
  • .Site.Sections
  • .Site.Title
  • .Site.Params
  • .File - the path was already defined before the template is parsed
  • .GitInfo

The intention of this list was to extend it with variables that might be used in an archetype template. Furthermore, I tried to keep the overhead low. Hugo shouldn't parse all existing pages in order to know what taxonomies etc already exists. Please correct me if my assumption of the internal implementation of some of the aforementioned vars is in conflict with this goal.

For the sake of interest: is it possible to call partials within a front matter template?

[bep]

For the sake of interest: is it possible to call partials within an archetype template?

Yes, but that sounds a little bit strange...? But I don't see any problems with it, do you (we could remove the partial template func in this case)?

• Re .Site, I will handle that in Add .Site to archetypes templating #1629 -- there are some non-trivial decisions to make, and this PR is usable as it is.
• Re. File; I thought about it, and ... maybe. But what is the potential use case(s)?
• GitInfo: We are creating a brand new file that is then written to disk. What info would you expect to find in GitInfo for this file?

[digitalcraftsman]

Yes, but that sounds a little bit strange...? But I don't see any problems with it, do you (we could remove the partial template func in this case)?

Strange? Maybe. I don't think users will have such complex front matter templates that they would have the need to split it up into partials.

Should we remove it? I don't see no reason why it should be bad to leave it. Currently, we can say you can use every template function which a reference to them without having to list exceptions.

Re. File; I thought about it, and ... maybe. But what is the potential use case(s)?

Personally I don't have any.

GitInfo: We are creating a brand new file that is then written to disk. What info would you expect to find in GitInfo for this file?

I've looked twice at the available variables and they don't provide not many usecases in a front matter. Let's forget this proposal

[bep]

@digitalcraftsman look at my second commit. I rethought the "File" question; it will not have Content(yet), but it is a familiar API (documented), so let's use that. Type and Date I guess we can keep as is?

[digitalcraftsman]

This looks like a good alternative.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.