Look into officially supporting Hugo in addition to Jekyll

[voxpelli]

Should be simple, as they are very similar

Things that should probably be looked at:

• Slug generation
• Permalink generation
• Post's file location, support other target than _post/. See Configurable file names and paths #6
• Add way to indicate whether it's a Jekyll site, Hugo site or something else. Jekyll can still be default. Could eg. add a new type option to the constructor and have that be set to 'hugo' to indicate that it's a Hugo site that should be generated. Or maybe extend the base Formatter and expose a HugoFormatter?
• ...

[keithjgrant]

Looks like this will require a way to customize the path where the file gets written. The _posts directory is a Jekyll convention.

In Hugo, the file needs to be saved in a "content" directory, and the subdir path matches the URL path. In my instance, I'd like to save the file to content/notes/:year/:month/:slug.md. Ideally, the "notes" part of that path would be customizable based on the post type or category -- but that's just my personal convention I've come up with and am flexible if there's a more standard approach.

[keithjgrant]

I started taking a look at this. Here's what I’ve got, but would appreciate your feedback. I want to make use of your jekyllUtils.generateUrl to support :year type placeholders in the path definition. This requires getting the jekyllResource, but calling _getJekyllResource() from within formatFilename produced an infinite loop.

Instead, I sort of stubbed the jekyllResource with only the relevant pieces of data, but this feels a bit dirty to me. Curious if you have thoughts for a better approach:

keithjgrant@116591b

[strugee]

I'd suggest that adding support for individual blogging engines will probably lead to feature bloat, etc. I think a better way to do this would be to write a way to configure the module for different storage formats. Configurations for each engine could then be passed around as e.g. npm modules.

[voxpelli]

@strugee I generally agree, although Hugo and Jekyll are so similar that I think it could make sense to have one module that supports all "Jekyll:ish" engines.

It's all a matter of whether one considers there to be an engine independent format for posts or not. To me it does look like Hugo and Jekyll both support the same format and then this module could support that shared format and just make it configurable enough to support the cases where they differ – like in which directory the files are put and probably how the slugs are generated.

If someone were to eg. want to support Middleman or something similar that has entirely different format, then I totally agree that it should be a different module (although ideally with the same API).

Thinking out loud now, but what one could do to keep a clean separation is to have an additional engine, like maybe Hugo, extend the base Formatter and create a new HugoFormatter. Initially as part of this module, but later – if there's a benefit of it – as its own module.

Sounds sensible?

[strugee]

Yeah, that makes sense to me generally.

[joshdick]

I know this issue is several years old now, but I would love to see Hugo support! I'm currently using this package in https://github.com/joshdick/microstat and am currently (messily) string-replacing the tags output of the final formatted content to be formatted as a YAML list, which is seemingly the only change needed to get Hugo minimally working -- at least it's working for me!