Shouldn't we reference theme components as project components?

[regisphilibert]

Hugo's currently underused theme components (unless as a good old theme) sport almost the same capacity as any project:

• config files
• data files
• layout files

There are even discussions of letting components sports their own content directory.

I think the "theme" word limits the concept to a skinning/layout utility while Hugo's components are much more powerful than that. They simplify the usage of a service such as cloudinary, they can add output formats, improve SEO, serve as boilerplate, etc... They are themes, plugins, extensions and more and the way they are publicized should better reflect their almost limitless potential.

I think project components or just hugo components is the way to go, but others might have better suggestions.

Then what would be left to discuss is the proper way to tag each components so people easily understand their impact.

[bep]

I agree with the basic premise in this issue, we should market this better.

I don't like "project component"; Hugo Components has a nicer ring to it -- and fits nicely side-by-side with Hugo Pipes

[kaushalmodi]

I also like "Hugo Components" name, but just a thought .. we still need to add those Components to the the theme config parameter.

[bep]

@kaushalmodi this particular topic is about the baby name.

[regisphilibert]

I also like "Hugo Components" name, but just a thought .. we still need to add those Components to the the theme config parameter.

Yes and this could lead to confusion, but we can talk about this theme key later I suppose.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help. If you still think this is important, please tell us why. This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[bep]

@kaushalmodi @regisphilibert @onedrawingperday and others: I think this topic needs a revival. I'm pretty soon going to release a Hugo version with Go Modules support, and with that I'm going to create wrappers around a subset of Go's module commands -- and I think it will be confusing if I named them something else, so go mod vendor becomes hugo mod vendor etc.

With that I feel that it is also best to use the Module term when talking about this stuff.

https://github.com/golang/go/wiki/Modules#modules

A module is a collection of related Go packages that are versioned together as a single unit.

A module is defined by a tree of Go source files with a go.mod file in the tree's root directory. Module source code may be located outside of GOPATH.

Etc.

So I suggest a definition in the line of:

A Hugo Module is a tree of Hugo Components that are versioned together as a single unit. When two components in the tree use the same resource name, e.g. layouts/partials/footer.html, the first (highest in the tree) variant will win.

There are some important missing pieces about versioning in the above, but if we could agree about that basic outline, it would be a great start.

Note that Hugo Module will be a general term that covers all of what we have been calling a project, a theme, a theme component.

[onedrawingperday]

Hugo Modules makes sense as a term to me and I agree with the above definition.

[regisphilibert]

I’m not sure module as defined by Go Lang will reach to common users.

To me as a user (familiar with the notion of plugins, extensions, packages, etc...) I see components as modules. I did not realize in the Go sense that a module was a group/set of components, and I doubt many current and future Hugo users will.

According to Wiktionary:

Module: A self-contained component of a system, often interchangeable, which has a well-defined interface to the other components.

I think defining the complete set of components as the « module », while being technically faithful to the programming concept of the feature, might be confusing to end-users and hard to explain.

For all of the above I’m pushing for Hugo Modules, plural, understanding that from the definition above the « system » is the site (sites if multilingual).

[regisphilibert]

I would add that the fact that a Module can contain/import other modules is assumed by most npm users.

[bep]

@regisphilibert we need term for what they in Go call a module and a package.

• In Go a module is a tree of packages with a specific version.

I think that the version part is easy to miss out on in this discussion, but this is superimportant. Your project, theme, theme component will all get a version allowing reproducible builds etc.

And if you want to pin a version on something, it needs to be "one thing", so whatever we call that, it is something singular (in my head).

So, if we call this feature Hugo Modules, your project/theme would still be a module.

We could, of course, call it something completely different, but since what we use under the hood (some of the commands in Hugo, like hugo mod get) is just very shallow wrappers, I think it helps to keep the naming somewhat related. Go Modules is designed and implemented by the second smartest person in Google (after Jeff Dean ...), and I think people need/want to know that this isn't something that I have mocked together in a weekend.

Also, I'm not too worried about using unfamiliar terms or even creating totally new terms ("Hugo Fox Holes") as long as we are consistent in using them (aka Hugo Pipes).

[larzza]

Isn't there a possibility that Go modules will be used for other features than "theme-composition" in the future? If so, will such features fit under the Hugo Module concept, or will they require their own names, even though Go modules are used under the hood?

[bep]

I'l leave this open for now. We don't have the development manpower to do anything about this at the moment, either -- and we'll need to play with this a little with real projects to know how it shapes.

[larzza]

Yes, I understand. What I was aiming at was that naming the feature Hugo modules just because it uses Go modules under the hood might not be a convincing argument, especially if the relationship isn´t one to one and Go modules might be used for other features in the future.

With that said, Hugo modules might very well, on its own merits so to speak, be a good name for the feature.

[bep]

@larzza I thought I commented on another issue (the one about the config var, e.g. theme). I think that whatever feature we put into this, Hugo Modules will not be totally misleading.

Also, I'm mirroring the Go comands, so it's hugo mod graph etc., so the mod (short for module(s)) will be in there, at least.

[larzza]

:-) thought your answer was a bit cryptic, but I managed to make some sense out of it.

I think the mod command name absolutely can/should be mirroring the go commands. But conceptually, i.e. how to describe the features in the documentation, there could be ”Hugo components” and ”Hugo-third-party-dependencies”, something like that.

Anyway, I think you´re doing a great job with this and probably know what you are doing also with the naming.

[bep]

I arrived back at this issue while looking at my source code for this where the naming is currently... less than perfect.

So, whether we name this module or component, people will come from different backgrounds and will put their own meaning into it.

In Hugo we have some precedence for naming things from Scandinavian rock/pop bands (baseof.ace), so ...

https://en.wikipedia.org/wiki/Mods_(band)

How about Hugo Mods? Which I guess would be plural of Mod and could mean module or modification... but is abstract enough so we can make it "our own".

[regisphilibert]

I think Hugo Mods would work just fine, I'm not sure about the necessity for Hugo to have its own word, but then again, I think it's cool that it does. Also, I'm not too opinionated about the final decision here, as long as it's plural and intuitive and Hugo Mods is both.

After this quasi acquiescing I would just to add the following:

I always thought the essence of Hugo theme/components were Hugo’s unison filesystem which works with layers of directories overriding homonymous files following a a user defined precedence.

This is because of this that people will be able to build so much powerful stuff out of Hugo's Components/Modules/Mods/xxx. For for some time, I entertained the idea of trying to find a word which also conveyed this important notion. And Layers was appealing.

Just like layers stacked on top of each other: any printed part of the layer on top will hide overlapping parts of any layers below. So... Hugo Layers. It is plural, it does convey the overriding logic, yet it is not intuitive, people will have to go and read what this stand for.

I guess my point is yes for Hugo Mods, unless someone out there has a word which would on top of modularity, also convey the current theme's overwriting logic while being more intuitive than Layers... Because if such a word exist, I'd vote for that!

[larzza]

I really hope that it someday (soon) will be possible to add the content as a Go-module (https://github.com/gohugoio/hugo/issues/5973). Conceptually I do not think that either module, mods, component or layer is a very good name in that case. But I might be wrong...

[onedrawingperday]

Hugo Layers.

Reminds me of all the image/vector editing and desktop publishing apps. Layers is a term too loaded with other meaning for the design crowd.

I do not currently have another term to propose though...

[larzza]

To keep away from how things work technically (Go modules, union file systems) and also hold a distance from well known software engineering concepts like components, modules, add-ons, plugins etc I ended up with this rolling around in my head:

Hugo Parts

How about that?

[larzza]

Hugo Parts and Hugo Pipes ... I still kind of like it. No one else...? @bep ?

[bep]

Just like layers stacked on top of each other: any printed part of the layer on top will hide overlapping parts of any layers below. So... Hugo Layers.

You are right about the powers of layers (and believe me when I'm telling you that you're going to be impressed by the power that comes with "auto downloading" of these layers); take a theme and add some prettier icons and buttons. But composition gets, I think, an equally important word, which may be more obvious in the content use case ...

How about Hugo Cake ... :-)

[regisphilibert]

How about Hugo Cake ... :-)

Nope. 🍰

[budparr]

I thought mods was good. I like to think of them just like node_modules that we use every day. I understand that modules brings baggage with it, but mods is close to that.

[kaushalmodi]

+1 for mods.

Pipes .. we already have Hugo pipes and that means something different altogether.

Cake .. nope.

Parts .. feels too mechanical.

Other ideas: Hugo Blocks, Hugo Bricks, Hugo Lego (but would violate the trademark :P).

[larzza]

@kaushalmodi I wrote out Pipes not as a name suggestion but as a comparison to Parts. Pipes are good, I use them all the time.

@bep Mods will be fine, but I like Hugo Cake even better, it’s so good that I’ll have a piece right away ;-)

[regisphilibert]

I still think:

1. should be plural
2. should not be food

[bep]

should not be food

How about Hugo Coctails (starring Tom Cruise)?

[bep]

Jokes aside.

@zivbk1 mentioned in https://github.com/gohugoio/hugo/issues/5973 that the content variant of this reminded him of https://docs.antora.org/antora/2.0/playbook/ -- and that is true.

And while content is something else, it will use the same technical foundation, so it helps to look at both when thinking about them. They talk about a playbook where you can combine ui bundles, content components etc. I have used some of the terms found there.

I know I'm about to take us back to the start here, but if we just say that "a module is a way to package and version your components" and that a component comes in different flavors defined by its scope:

• content-component (provides /content)
• layouts-component (provides /layouts)
• data-component (provides /data)
• theme-component provide what we think of as a theme today (/* except /content).

The component names above do not mean much, but I think it helps having something to cling on to when talking about them.

There will then typically be:

• Config options only relevant for a particular scope (/content, /*)
• Some limitations for what you can put into a component; e.g. /content is content only and only the main project can depend on content components (probably).

Which gives:

Hugo Modules (or Hugo Mods) is a way to manage your Hugo Components.

[larzza]

Yes!

• In my mind Hugo Mods are tight connected to Go Modules (for now at least).
• Hugo Components are what I suggested could be named Hugo Parts.

[regisphilibert]

We should consider Hugo Stack for the « components manager » which resonate nicely with you know what and convey the notion of layers I think.

Naming the components « Stacks » might work as well I suppose but know I understand the need to reference the two notions differently.

There are the modules / components And there is the modules / components manager.

[jmooring]

This train left the station a long time ago --> Hugo Modules.