mirror of
https://github.com/gohugoio/hugo.git
synced 2025-08-26 22:04:32 +02:00
Bjørn Erik Pedersen
@@ -1,29 +0,0 @@
|
||||
---
|
||||
title: Hugo Modules
|
||||
linkTitle: Overview
|
||||
description: How to use Hugo Modules.
|
||||
categories: []
|
||||
keywords: []
|
||||
menu:
|
||||
docs:
|
||||
identifier: hugo-modules-overview
|
||||
parent: modules
|
||||
weight: 10
|
||||
weight: 10
|
||||
toc: true
|
||||
aliases: [/themes/overview/,/themes/]
|
||||
---
|
||||
|
||||
**Hugo Modules** are the core building blocks in Hugo. A _module_ can be your main project or a smaller module providing one or more of the 7 component types defined in Hugo: **static**, **content**, **layouts**, **data**, **assets**, **i18n**, and **archetypes**.
|
||||
|
||||
You can combine modules in any combination you like, and even mount directories from non-Hugo projects, forming a big, virtual union file system.
|
||||
|
||||
Hugo Modules are powered by Go Modules. For more information about Go Modules, see:
|
||||
|
||||
- [https://github.com/golang/go/wiki/Modules](https://github.com/golang/go/wiki/Modules)
|
||||
- [https://go.dev/blog/using-go-modules](https://go.dev/blog/using-go-modules)
|
||||
|
||||
Some example projects:
|
||||
|
||||
- [https://github.com/bep/docuapi](https://github.com/bep/docuapi) is a theme that has been ported to Hugo Modules while testing this feature. It is a good example of a non-Hugo-project mounted into Hugo’s folder structure. It even shows a JS Bundler implementation in regular Go templates.
|
||||
- [https://github.com/bep/my-modular-site](https://github.com/bep/my-modular-site) is a very simple site used for testing.
|
||||
@@ -1,181 +0,0 @@
|
||||
---
|
||||
title: Configure Hugo modules
|
||||
description: This page describes the configuration options for a module.
|
||||
categories: [hugo modules]
|
||||
keywords: [modules,themes]
|
||||
menu:
|
||||
docs:
|
||||
parent: modules
|
||||
weight: 20
|
||||
weight: 20
|
||||
toc: true
|
||||
---
|
||||
|
||||
## Module configuration: top level
|
||||
|
||||
{{< code-toggle file=hugo >}}
|
||||
[module]
|
||||
noProxy = 'none'
|
||||
noVendor = ''
|
||||
private = '*.*'
|
||||
proxy = 'direct'
|
||||
replacements = ''
|
||||
vendorClosest = false
|
||||
workspace = 'off'
|
||||
{{< /code-toggle >}}
|
||||
|
||||
noProxy
|
||||
: Comma separated glob list matching paths that should not use the proxy configured above.
|
||||
|
||||
noVendor
|
||||
: A optional Glob pattern matching module paths to skip when vendoring, e.g. "github.com/**"
|
||||
|
||||
private
|
||||
: Comma separated glob list matching paths that should be treated as private.
|
||||
|
||||
proxy
|
||||
: Defines the proxy server to use to download remote modules. Default is `direct`, which means "git clone" and similar.
|
||||
|
||||
vendorClosest
|
||||
: When enabled, we will pick the vendored module closest to the module using it. The default behavior is to pick the first. Note that there can still be only one dependency of a given module path, so once it is in use it cannot be redefined.
|
||||
|
||||
workspace
|
||||
: The workspace file to use. This enables Go workspace mode. Note that this can also be set via OS env, e.g. `export HUGO_MODULE_WORKSPACE=/my/hugo.work` This only works with Go 1.18+. In Hugo `v0.109.0` we changed the default to `off` and we now resolve any relative work file names relative to the working directory.
|
||||
|
||||
replacements
|
||||
: A comma-separated list of mappings from module paths to directories, e.g. `github.com/bep/my-theme -> ../..,github.com/bep/shortcodes -> /some/path`. This is mostly useful for temporary local development of a module, in which case you might want to save it as an environment variable, e.g: `env HUGO_MODULE_REPLACEMENTS="github.com/bep/my-theme -> ../.."`. Relative paths are relative to [themesDir](/getting-started/configuration/#all-configuration-settings). Absolute paths are allowed.
|
||||
|
||||
Note that the above terms maps directly to their counterparts in Go Modules. Some of these setting may be natural to set as OS environment variables. To set the proxy server to use, as an example:
|
||||
|
||||
```txt
|
||||
env HUGO_MODULE_PROXY=https://proxy.example.org hugo
|
||||
```
|
||||
|
||||
{{< gomodules-info >}}
|
||||
|
||||
## Module configuration: hugoVersion
|
||||
|
||||
If your module requires a particular version of Hugo to work, you can indicate that in the `module` section and the user will be warned if using a too old/new version.
|
||||
|
||||
{{< code-toggle file=hugo >}}
|
||||
[module]
|
||||
[module.hugoVersion]
|
||||
min = ""
|
||||
max = ""
|
||||
extended = false
|
||||
|
||||
{{< /code-toggle >}}
|
||||
|
||||
Any of the above can be omitted.
|
||||
|
||||
min
|
||||
: The minimum Hugo version supported, e.g. `0.55.0`
|
||||
|
||||
max
|
||||
: The maximum Hugo version supported, e.g. `0.55.0`
|
||||
|
||||
extended
|
||||
: Whether the extended version of Hugo is required.
|
||||
|
||||
## Module configuration: imports
|
||||
|
||||
{{< code-toggle file=hugo >}}
|
||||
[module]
|
||||
[[module.imports]]
|
||||
path = "github.com/gohugoio/hugoTestModules1_linux/modh1_2_1v"
|
||||
ignoreConfig = false
|
||||
ignoreImports = false
|
||||
disable = false
|
||||
[[module.imports]]
|
||||
path = "my-shortcodes"
|
||||
{{< /code-toggle >}}
|
||||
|
||||
path
|
||||
: Can be either a valid Go Module module path, e.g. `github.com/gohugoio/myShortcodes`, or the directory name for the module as stored in your themes folder.
|
||||
|
||||
ignoreConfig
|
||||
: If enabled, any module configuration file, e.g. `hugo.toml`, will not be loaded. Note that this will also stop the loading of any transitive module dependencies.
|
||||
|
||||
ignoreImports
|
||||
: If enabled, module imports will not be followed.
|
||||
|
||||
disable
|
||||
: Set to `true` to disable the module while keeping any version info in the `go.*` files.
|
||||
|
||||
noMounts
|
||||
: Do not mount any folder in this import.
|
||||
|
||||
noVendor
|
||||
: Never vendor this import (only allowed in main project).
|
||||
|
||||
{{< gomodules-info >}}
|
||||
|
||||
## Module configuration: mounts
|
||||
|
||||
{{% note %}}
|
||||
When the `mounts` configuration was introduced in Hugo 0.56.0, we were careful to preserve the existing `contentDir`, `staticDir`, and similar configuration to make sure all existing sites just continued to work. But you should not have both: if you add a `mounts` section you should remove the old `contentDir`, `staticDir`, etc. settings.
|
||||
{{% /note %}}
|
||||
|
||||
{{% note %}}
|
||||
When you add a mount, the default mount for the concerned target root is ignored: be sure to explicitly add it.
|
||||
{{% /note %}}
|
||||
|
||||
**Default mounts**
|
||||
{{< code-toggle file=hugo >}}
|
||||
[module]
|
||||
[[module.mounts]]
|
||||
source="content"
|
||||
target="content"
|
||||
[[module.mounts]]
|
||||
source="static"
|
||||
target="static"
|
||||
[[module.mounts]]
|
||||
source="layouts"
|
||||
target="layouts"
|
||||
[[module.mounts]]
|
||||
source="data"
|
||||
target="data"
|
||||
[[module.mounts]]
|
||||
source="assets"
|
||||
target="assets"
|
||||
[[module.mounts]]
|
||||
source="i18n"
|
||||
target="i18n"
|
||||
[[module.mounts]]
|
||||
source="archetypes"
|
||||
target="archetypes"
|
||||
{{< /code-toggle >}}
|
||||
|
||||
source
|
||||
: The source directory of the mount. For the main project, this can be either project-relative or absolute and even a symbolic link. For other modules it must be project-relative.
|
||||
|
||||
target
|
||||
: Where it should be mounted into Hugo's virtual filesystem. It must start with one of Hugo's component folders: `static`, `content`, `layouts`, `data`, `assets`, `i18n`, or `archetypes`. E.g. `content/blog`.
|
||||
|
||||
lang
|
||||
: The language code, e.g. "en". Only relevant for `content` mounts, and `static` mounts when in multihost mode.
|
||||
|
||||
includeFiles (string or slice)
|
||||
: One or more [glob](https://github.com/gobwas/glob) patterns matching files or directories to include. If `excludeFiles` is not set, the files matching `includeFiles` will be the files mounted.
|
||||
|
||||
The glob patterns are matched to the file names starting from the `source` root, they should have Unix styled slashes even on Windows, `/` matches the mount root and `**` can be used as a super-asterisk to match recursively down all directories, e.g `/posts/**.jpg`.
|
||||
|
||||
The search is case-insensitive.
|
||||
|
||||
excludeFiles (string or slice)
|
||||
: One or more glob patterns matching files to exclude.
|
||||
|
||||
**Example**
|
||||
{{< code-toggle file=hugo >}}
|
||||
[module]
|
||||
[[module.mounts]]
|
||||
source="content"
|
||||
target="content"
|
||||
excludeFiles="docs/*"
|
||||
[[module.mounts]]
|
||||
source="node_modules"
|
||||
target="assets"
|
||||
[[module.mounts]]
|
||||
source="assets"
|
||||
target="assets"
|
||||
{{< /code-toggle >}}
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
title: Theme components
|
||||
description: Hugo provides advanced theming support with Theme Components.
|
||||
categories: [hugo modules]
|
||||
keywords: [modules,themes]
|
||||
menu:
|
||||
docs:
|
||||
parent: modules
|
||||
weight: 40
|
||||
weight: 40
|
||||
aliases: [/themes/customize/,/themes/customizing/]
|
||||
toc: true
|
||||
---
|
||||
|
||||
{{% note %}}
|
||||
This section contain information that may be outdated and is in the process of being rewritten.
|
||||
{{% /note %}}
|
||||
Since Hugo `0.42` a project can configure a theme as a composite of as many theme components you need:
|
||||
|
||||
{{< code-toggle file=hugo >}}
|
||||
theme = ["my-shortcodes", "base-theme", "hyde"]
|
||||
{{< /code-toggle >}}
|
||||
|
||||
You can even nest this, and have the theme component itself include theme components in its own `hugo.toml` (theme inheritance).[^1]
|
||||
|
||||
The theme definition example above in `hugo.toml` creates a theme with 3 theme components with precedence from left to right.
|
||||
|
||||
For any given file, data entry, etc., Hugo will look first in the project and then in `my-shortcodes`, `base-theme`, and lastly `hyde`.
|
||||
|
||||
Hugo uses two different algorithms to merge the file systems, depending on the file type:
|
||||
|
||||
* For `i18n` and `data` files, Hugo merges deeply using the translation ID and data key inside the files.
|
||||
* For `static`, `layouts` (templates), and `archetypes` files, these are merged on file level. So the left-most file will be chosen.
|
||||
|
||||
The name used in the `theme` definition above must match a folder in `/your-site/themes`, e.g. `/your-site/themes/my-shortcodes`. There are plans to improve on this and get a URL scheme so this can be resolved automatically.
|
||||
|
||||
Also note that a component that is part of a theme can have its own configuration file, e.g. `hugo.toml`. There are currently some restrictions to what a theme component can configure:
|
||||
|
||||
* `params` (global and per language)
|
||||
* `menu` (global and per language)
|
||||
* `outputformats` and `mediatypes`
|
||||
|
||||
The same rules apply here: The left-most parameter/menu etc. with the same ID will win. There are some hidden and experimental namespace support in the above, which we will work to improve in the future, but theme authors are encouraged to create their own namespaces to avoid naming conflicts.
|
||||
|
||||
[^1]: For themes hosted on the [Hugo Themes Showcase](https://themes.gohugo.io/) components need to be added as git submodules that point to the directory `exampleSite/themes`
|
||||
@@ -1,161 +0,0 @@
|
||||
---
|
||||
title: Use Hugo Modules
|
||||
description: How to use Hugo Modules to build and manage your site.
|
||||
categories: [hugo modules]
|
||||
keywords: [modules,themes]
|
||||
menu:
|
||||
docs:
|
||||
parent: modules
|
||||
weight: 30
|
||||
weight: 30
|
||||
aliases: [/themes/usage/,/themes/installing/,/installing-and-using-themes/]
|
||||
toc: true
|
||||
---
|
||||
|
||||
## Prerequisite
|
||||
|
||||
{{< gomodules-info >}}
|
||||
|
||||
## Initialize a new module
|
||||
|
||||
Use `hugo mod init` to initialize a new Hugo Module. If it fails to guess the module path, you must provide it as an argument, e.g.:
|
||||
|
||||
```sh
|
||||
hugo mod init github.com/gohugoio/myShortcodes
|
||||
```
|
||||
|
||||
Also see the [CLI Doc](/commands/hugo_mod_init/).
|
||||
|
||||
## Use a module for a theme
|
||||
|
||||
The easiest way to use a Module for a theme is to import it in the configuration.
|
||||
|
||||
1. Initialize the hugo module system: `hugo mod init github.com/<your_user>/<your_project>`
|
||||
2. Import the theme:
|
||||
|
||||
{{< code-toggle file=hugo >}}
|
||||
[module]
|
||||
[[module.imports]]
|
||||
path = "github.com/spf13/hyde"
|
||||
{{< /code-toggle >}}
|
||||
|
||||
## Update modules
|
||||
|
||||
Modules will be downloaded and added when you add them as imports to your configuration, see [Module Imports](/hugo-modules/configuration/#module-configuration-imports).
|
||||
|
||||
To update or manage versions, you can use `hugo mod get`.
|
||||
|
||||
Some examples:
|
||||
|
||||
### Update all modules
|
||||
|
||||
```sh
|
||||
hugo mod get -u
|
||||
```
|
||||
|
||||
### Update all modules recursively
|
||||
|
||||
```sh
|
||||
hugo mod get -u ./...
|
||||
```
|
||||
|
||||
### Update one module
|
||||
|
||||
```sh
|
||||
hugo mod get -u github.com/gohugoio/myShortcodes
|
||||
```
|
||||
|
||||
### Get a specific version
|
||||
|
||||
```sh
|
||||
hugo mod get github.com/gohugoio/myShortcodes@v1.0.7
|
||||
```
|
||||
|
||||
Also see the [CLI Doc](/commands/hugo_mod_get/).
|
||||
|
||||
## Make and test changes in a module
|
||||
|
||||
One way to do local development of a module imported in a project is to add a replace directive to a local directory with the source in `go.mod`:
|
||||
|
||||
```sh
|
||||
replace github.com/bep/hugotestmods/mypartials => /Users/bep/hugotestmods/mypartials
|
||||
```
|
||||
|
||||
If you have the `hugo server` running, the configuration will be reloaded and `/Users/bep/hugotestmods/mypartials` put on the watch list.
|
||||
|
||||
Instead of modifying the `go.mod` files, you can also use the modules configuration [`replacements`](/hugo-modules/configuration/#module-configuration-top-level) option.
|
||||
|
||||
## Print dependency graph
|
||||
|
||||
Use `hugo mod graph` from the relevant module directory and it will print the dependency graph, including vendoring, module replacement or disabled status.
|
||||
|
||||
E.g.:
|
||||
|
||||
```txt
|
||||
hugo mod graph
|
||||
|
||||
github.com/bep/my-modular-site github.com/bep/hugotestmods/mymounts@v1.2.0
|
||||
github.com/bep/my-modular-site github.com/bep/hugotestmods/mypartials@v1.0.7
|
||||
github.com/bep/hugotestmods/mypartials@v1.0.7 github.com/bep/hugotestmods/myassets@v1.0.4
|
||||
github.com/bep/hugotestmods/mypartials@v1.0.7 github.com/bep/hugotestmods/myv2@v1.0.0
|
||||
DISABLED github.com/bep/my-modular-site github.com/spf13/hyde@v0.0.0-20190427180251-e36f5799b396
|
||||
github.com/bep/my-modular-site github.com/bep/hugo-fresh@v1.0.1
|
||||
github.com/bep/my-modular-site in-themesdir
|
||||
```
|
||||
|
||||
Also see the [CLI Doc](/commands/hugo_mod_graph/).
|
||||
|
||||
## Vendor your modules
|
||||
|
||||
`hugo mod vendor` will write all the module dependencies to a `_vendor` folder, which will then be used for all subsequent builds.
|
||||
|
||||
Note that:
|
||||
|
||||
* You can run `hugo mod vendor` on any level in the module tree.
|
||||
* Vendoring will not store modules stored in your `themes` folder.
|
||||
* Most commands accept a `--ignoreVendorPaths` flag, which will then not use the vendored modules in `_vendor` for the module paths matching the [Glob](https://github.com/gobwas/glob) pattern given.
|
||||
|
||||
Also see the [CLI Doc](/commands/hugo_mod_vendor/).
|
||||
|
||||
## Tidy go.mod, go.sum
|
||||
|
||||
Run `hugo mod tidy` to remove unused entries in `go.mod` and `go.sum`.
|
||||
|
||||
Also see the [CLI Doc](/commands/hugo_mod_clean/).
|
||||
|
||||
## Clean module cache
|
||||
|
||||
Run `hugo mod clean` to delete the entire modules cache.
|
||||
|
||||
Note that you can also configure the `modules` cache with a `maxAge`, see [File Caches](/getting-started/configuration/#configure-file-caches).
|
||||
|
||||
Also see the [CLI Doc](/commands/hugo_mod_clean/).
|
||||
|
||||
## Module workspaces
|
||||
|
||||
{{< new-in 0.109.0 >}}
|
||||
|
||||
Workspace support was added in [Go 1.18](https://go.dev/blog/get-familiar-with-workspaces) and Hugo got solid support for it in the `v0.109.0` version.
|
||||
|
||||
A common use case for a workspace is to simplify local development of a site with its theme modules.
|
||||
|
||||
A workspace can be configured in a `*.work` file and activated with the [module.workspace](/hugo-modules/configuration/) setting, which for this use is commonly controlled via the `HUGO_MODULE_WORKSPACE` OS environment variable.
|
||||
|
||||
See the [hugo.work](https://github.com/gohugoio/hugo/blob/master/docs/hugo.work) file in the Hugo Docs repo for an example:
|
||||
|
||||
```text
|
||||
go 1.20
|
||||
|
||||
use .
|
||||
use ../gohugoioTheme
|
||||
```
|
||||
|
||||
Using the `use` directive, list all the modules you want to work on, pointing to its relative location. As in the example above, it's recommended to always include the main project (the ".") in the list.
|
||||
|
||||
With that you can start the Hugo server with that workspace enabled:
|
||||
|
||||
```sh
|
||||
HUGO_MODULE_WORKSPACE=hugo.work hugo server --ignoreVendorPaths "**"
|
||||
```
|
||||
|
||||
The `--ignoreVendorPaths` flag is added above to ignore any of the vendored dependencies inside `_vendor`. If you don't use vendoring, you don't need that flag. But now the server is set up watching the files and directories in the workspace and you can see your local edits reloaded.
|
||||
Reference in New Issue
Block a user