If you can build Hugo from source and are willing to take the latest master for a spin, it would be appreciated. I have tested this to no ends myself, and the test coverage is good, but the more the merrier …
I’m mostly interested in knowing that your existing sites works as before, but if you want to take this new feature for a spin, great! I think it will be very powerful once you wrap your head around it.
Probably just stating the obvious… but if a theme has dependencies i.e. if a theme is composed of other themes/components, the theme’s README should instruct the user to do the multiple git clones, right?
I mean, does the theme directory structure look like this?:
Yes. I thought I was clear about this in the commit message. As it is now, it is your responsible to match the folder names in /themes with the definition in config.toml. This is how it it behaves even before this feature.
This isn’t that hard, but we will eventually have to do better. But there is a point made to take one step at a time.
I could probably have come up with something half-baked here (using the name from config.toml), but I have some half-thought ideas about something much, much better (hugo get).
Oh, and @kaushalmodi those repositories are shiny examples of the power of this feature. Want an atom feed? Just plug this in … Is way much better than “follow this 32 step tutorial to get an Atom feed …”
I just tested the hugo-debugprint theme component on three of my sites. It worked as expected. On one site I had to make a small adjustment to how I included a custom partial, I guess I was doing it in a now deprecated way.
Hmm. That is the first time I have seen a construct like that. Yes, that will not work with the new setup, and will be very expensive to maintain if we would add support for it. But thanks for the heads up. I will make a note in the release notes.
Earlier if someone cloned a foo theme as bar, they just needed to do theme = "bar".
But now, if a foo theme has components, it would have theme = ["foo", "foo-component"] in its config.toml.
So now a user has to update their site config + “pollute” the cloned theme’s config.toml (pollute in the sense that they can no longer git pull it easily in future as they tweaked the theme by editing its config.toml).
So…
Keep original names of themes and their components when you clone them.
I don’t mind that rule… just that it has to be made clear in the release notes.
This isn’t that hard, but we will eventually have to do better. But there is a point made to take one step at a time.
+1
Understood. Thanks for this feature, though. It works perfectly! I’m already using the theme components on 4 sites… no more manually copy/pasting of changes across multiple sites!
You can probably lift this restriction from the naming of at least the naming of theme (not component) clones, if the theme variable recognized a special placeholder like "__this__"just inside a theme’s config.toml.
Does Hugo process an “assets” folder within a theme component? I would like to add components that require Javascript which needs to be transpiled. This is for a multi-page site with page specific js bundles.
Yes. Or, we don’t process the folder. But if you say resources.Get "mystyles.css" (as one example), we look for it in first the project and then the theme components (left to right).