I’d like the hugo new command to be nicer with my archetypes. I’m targeting less experienced users, so I’d like to put comments in my archetype files:
+++
## archetypes/post.md
Description = ""
Tags = ["topic1", "topic2", "etc"]
Categories = ["menu1", "menu2", "etc"]
menu = "main"
weight = 5
## uncomment if you want the post to disallow comments
#disallow_comments = "true"
+++
Running hugo new post/lorem-ipsum.md causes Hugo to read in that file and create content/post/lorem-ipsum.md. The front matter is read in by another package, which strips the comments, so Hugo loses them prior to creating the post. The result, to me, is that I can’t supply helpful comments for the end-user.
There’s a similar situation with the markdown. I’d like to put some text in the content area:
+++
. . .
+++
Markdown cheatsheet at https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet
This text is above the fold.
<!--more-->
This text is below the fold.
That content is also stripped before creating the post.
Right now, I have a workaround by using a shell script to set up everything, so this is certainly a “nice to have” item, not a “need it now.”
I completely agree. I think the concept behind hugo new is a step in the right direction, but there are many more steps.
In fact, I found your post when creating a post to see if there is interest in having hugo new look for an env var so I don’t have to be in the exact perfect place for it to work when I call the command. If there is enough interest perhaps we could open a thread and dialog about it. I image many of gotten around this annoyance in their own way, custom scripts, aliases, etc.
One quick way to get around the limitations of the archetype system is to use _.md files. I use these a lot. The _ means “archi/prototype” to me and I use this method for both stuff in content and data. Even without a helper cp _.md my-new-post-md works pretty well and like most shell folk I have a tstamp command of my own for adding in the time stamp. I just have to make sure all my templates ignore _.md in the .Pages list, which is something I wish Hugo did automatically.
In the data directory I use this and make liberal use of directories and subdirectories for modeling data defaulting to objects/maps over arrays/slices/lists any time I can. TOML currently does not support the field = {some="thing} syntax, which it declares in its spec, so subdirectories work. They also play more nicely with automation and navigation. Using cd to navigate your data model is pretty nice (v.s. the equivalent from a MongoDB REPL, for example. The _.toml file is the equivalent of a JavaScript prototype in my world. Not only does it give me something to copy and fill in when adding new data, It allows me to give all the objects properties that they all share unless overriden. Obviously the annoyance here is that I have to do the overriding logic in my templates. Eventually I am hoping to submit a PR for a protodata = true or something that allows this to happen automatically.
But back to the hugo new thing.
One major annoyance I have, that has caused me to all but not use hugo new is that as soon as I close the file I cannot open it again with the same command (by going back up in history). I mean, how many of us get it right on the first pass, lol. To open it a second time I have to go to the content/blog directory anyway so might as well just started out there.
It seems like hugo new and the like almost need their own project or subproject. One that focuses on working with the content and data directories.
On a related note I think Hugo could be simplified to not need hugo new site to begin. On the whole it could really benefit from some basic assumptions and simplified starting setup, but that one is less urgent to me.
Also, having looked through the code I see the support for multiple front matter formats (toml, json, yaml) pretty much locks the code into parsing it all and then dumping the new content file in the desired MetaDataFormat. This makes it very unlikely a solution that does not remove comments and rearrange front-matter order will be possible and maintain backwards compatibility.
I agree with the thread starter that the Archetype file should be kept in order and with comments and all. There is an open issue about this – talking about implementing a more stupid parser (only inject the date if not present). I think that is a way to go, but someone needs to do it, and it is not at the very top of my list.
As to running “hugo new” anywhere in the file system, I’m not sure how that would work with multiple Hugo sites (I got plenty).
I actually don’t use “hugo new” at all. For me it’s totally superfluous. I use my editor, and I create a new blogpost like I create any new file elsewhere. After all, there is no “gcc new test.c” command or “python new foo.py”.
As for the boilerplate: many, if not all, editors have the ability to insert code snippets. When adding a boilerplate would be too tedious for me, I’d simply tell my editor to do this for me. In my case, one method would be to use a yasnippet. I’m sure other editors have similar capabilities.
I mean, how many of us get it right on the first pass, lol
Sure, almost no one. But in the editor I have a view of my git status of the project (here using magit). And so I quickly can go back to the file and re-edit. Or I use the list of recently opened files. Again no reason mimick such a feature into a static web site generator.
Yeah the more I looked into it I realized the problem for many, myself included, is the concept of front matter in general, which mixes meta data and content, a bad call in my opinion (although God knows everyone does it). The desire for comments in the front matter comes from a not-so-evil desire to document the pseudo-schema that emerges in front matter that grows in content that evolves into database like objects as some sites become more complex, which is where data comes in.
In short, I don’t use archetypes and never will. I have my own system of prototype data objects these days.