Migrate to Hugo Modules

[mnordhaus]

Hi to the Maintainers especially Adrian,

I am currently upgrading my personal website and like to use the adritian theme and plan on contributing to the project. Are you interested in migrating this theme into a Module and Modulize it in a reasonable way (I like that this theme is not overengineered).

Best,

Markus

[mnordhaus]

My Ideas are:

• turn the theme into a Hugo module
• divide the theme into reasonable modules (to be discussed here)

[zetxek]

Yes! It was something back of my mind for a while, but never got around it.

Is this something you could contribute with in some form?

As creating the theme started based in my own need - something I'm not fully familiar with is the advantage of modules.

I assume that getting updates might be easier for the theme users?
Do you know if using as a module discards or replaced using it as a git submodule?

And lastly, if you have a good theme module example in mind it can be useful for me took into as a reference :)

[mnordhaus]

Yes, my intention is to contribute those changes.

I do not think that there are much compatibility issues and you can still provide the theme via a git submodule. Something that uses modules is

• https://github.com/HugoBlox/hugo-blox-builder
• https://github.com/hugolify/

There are many others but those both use modules heavily and they are quite comprehensive. Hugo-Blox went down the Tailwind path - which is not a good decision.

Hugolify is in my point of view somehow a little bit over engineered. There needs to be a balance between modularity and readability and understandability of the architecture of a theme.

I think Adritian has a huge potential! So I am happy to invest some time into it.

My suggestion of a path forward is to provide a small PoC/Sample how it could look like?

• A fork of Adritian that can be added as a Module
• ... that is extracts Bootstrap as a Module (I think that helps a lot for maintainability)

Ah and yes! You do not need a Build tool like Webpack to use Modules!

[mnordhaus]

And by the way, I was about to write my own theme ... a somehow at the same point you have been back than ;-)

[mnordhaus]

And do you want me to track that through an issue or do we leave it here for discussion yet - until we commit to start?

[zetxek]

We could track it as an issue (we have a category "idea" :)

The plan sounds great! In some of the last releases I've tried to go back to plain bootstrap as much as possible, and customize with overrides.

I'd be happy to give a hand with it too - everything that keeps the theme simple and easy to use is great, and it seems that modules will definitely go in that direction.

[mnordhaus]

I just created a ticket: #165

[zetxek]

There is something I'm not fully convinced about with the modules.
If the theme uses bootstrap as a module - the codebase is not included in the theme. So far ok, as it's a leaner codebase.

But this also means that the theme is not "plug and play" when using submodules, or even when downloading the theme and just copying it to the themes folder of the users' website.

I feel that while modules are more developer-friendly, it's less "non technical users" friendly.
This might be the reason why the themes that use modules more extensively are more overengineered, as they are targeted to and created by a more technical audience.

I would like to keep the theme very accessible for anyone. This complexity makes me doubt on the value of modules for the final user...

[zetxek]

A solution to this complexity and allow the module to still be "plug and play" would mean to keep on distributing bootstrap within the theme...

[dcorto]

There is something I'm not fully convinced about with the modules. If the theme uses bootstrap as a module - the codebase is not included in the theme. So far ok, as it's a leaner codebase.

But this also means that the theme is not "plug and play" when using submodules, or even when downloading the theme and just copying it to the themes folder of the users' website.

I feel that while modules are more developer-friendly, it's less "non technical users" friendly. This might be the reason why the themes that use modules more extensively are more overengineered, as they are targeted to and created by a more technical audience.

I would like to keep the theme very accessible for anyone. This complexity makes me doubt on the value of modules for the final user...

You are right, with submodules you can't "plug and play" than easly, but at the end, for use hugo, you need at least have go installed, so i thing, the ecosystem in general is more focused for a technical users, this is not like a Wordpress theme. So i don't see a block here if is well documented on the README.md, as is in the pull request #166

You choose @zetxek. I'm comfortable with both systems, but not with the "two versions" 😄

[zetxek]

What i am leaning towards the most is to keep bootstrap embedded in the theme for now. that way it's still plug and play via git submodule (or a regular download) - and works for whoever uses modules too.

Especially as it's a critical dependency - without bootstrap the theme is not useful.

Maybe the modules system evolves with Hugo and will become the default for Hugo - in that case it'd be fully prepared.

💡What could work very well for modules are additional functionalities that are not core to the theme. For example search, image galleries...

[dcorto]

I tested modules in my repository (site) yesterday and realized that when you use the module you don't even need the theme/ folder, so it's only fair to keep the included version like you said, so as not to "bother" users who know use the themes via the "normal" method (as I understand it)

So for me let's follow this path and see how it evolves.

Good job!

[zetxek]

As an example of the added complexity - deploying to vercel was already more complex with modules that with submodules - because it requires to have go installed in the system that deploys (in this case, vercel):

zetxek/adritian-demo#144 (comment)