-
-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Look into officially supporting Hugo in addition to Jekyll #5
Comments
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 |
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 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: |
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. |
@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 Sounds sensible? |
Yeah, that makes sense to me generally. |
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 |
Should be simple, as they are very similar
Things that should probably be looked at:
_post/
. See Configurable file names and paths #6type
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 baseFormatter
and expose aHugoFormatter
?The text was updated successfully, but these errors were encountered: