mirror of
https://github.com/gohugoio/hugo.git
synced 2025-08-25 22:00:58 +02:00
Merge commit '5be51ac3db225d5df501ed1fa1499c41d97dbf65'
This commit is contained in:
Bjørn Erik Pedersen
@@ -1,29 +1,8 @@
|
||||
---
|
||||
title: Hugo Modules
|
||||
|
||||
description: Use Hugo Modules to manage the content, presentation, and behavior of your site.
|
||||
categories: []
|
||||
keywords: []
|
||||
menu:
|
||||
docs:
|
||||
identifier: hugo-modules-in-this-section
|
||||
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://go.dev/wiki/Modules](https://go.dev/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 directory 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,191 +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'
|
||||
auth = ''
|
||||
{{< /code-toggle >}}
|
||||
|
||||
noProxy
|
||||
: (`string`) Comma separated glob list matching paths that should not use the proxy configured above.
|
||||
|
||||
noVendor
|
||||
: (`string`) A optional Glob pattern matching module paths to skip when vendoring, e.g. "github.com/**"
|
||||
|
||||
private
|
||||
: (`string`) Comma separated glob list matching paths that should be treated as private.
|
||||
|
||||
proxy
|
||||
: (`string`) Defines the proxy server to use to download remote modules. Default is `direct`, which means "git clone" and similar.
|
||||
|
||||
auth
|
||||
: (`string`) {{< new-in 0.144.0 >}} Configures `GOAUTH` when running the Go command for module operations. This is a semicolon-separated list of authentication commands for go-import and HTTPS module mirror interactions. This is useful for private repositories. See `go help goauth` for more information.
|
||||
|
||||
vendorClosest
|
||||
: (`bool`) 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. Default is `false`.
|
||||
|
||||
workspace
|
||||
: (`string`) 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
|
||||
: (`string`) 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
|
||||
: (`string`) The minimum Hugo version supported, e.g. `0.55.0`
|
||||
|
||||
max
|
||||
: (`string`) The maximum Hugo version supported, e.g. `0.55.0`
|
||||
|
||||
extended
|
||||
: (`bool`) Whether the extended edition of Hugo is required, satisfied by installing either the extended or extended/deploy edition.
|
||||
|
||||
## 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` directory.
|
||||
|
||||
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 directory 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
|
||||
: (`string`) The source directory of the mount. For the main project, this can be either project-relative or absolute. For other modules it must be project-relative.
|
||||
|
||||
target
|
||||
: (`string`) Where it should be mounted into Hugo's virtual filesystem. It must start with one of Hugo's component directories: `static`, `content`, `layouts`, `data`, `assets`, `i18n`, or `archetypes`. E.g. `content/blog`.
|
||||
|
||||
disableWatch
|
||||
{{< new-in 0.128.0 />}}
|
||||
: (`bool`) Whether to disable watching in watch mode for this mount. Default is `false`.
|
||||
|
||||
lang
|
||||
: (`string`) The language code, e.g. "en". Only relevant for `content` mounts, and `static` mounts when in multihost mode.
|
||||
|
||||
includeFiles
|
||||
: (`string` or `[]string`) 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 `[]string`) 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 >}}
|
||||
19
docs/content/en/hugo-modules/introduction.md
Normal file
19
docs/content/en/hugo-modules/introduction.md
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: Introduction
|
||||
description: A brief introduction to Hugo Modules.
|
||||
categories: []
|
||||
keywords: []
|
||||
weight: 10
|
||||
---
|
||||
|
||||
Hugo uses modules as its fundamental organizational units. A module can be a full Hugo project or a smaller, reusable piece providing one or more of Hugo's seven component types: static files, content, layouts, data, assets, internationalization (i18n) resources, and archetypes.
|
||||
|
||||
Modules are combinable in any arrangement, and external directories (including those from non-Hugo projects) can be mounted, effectively creating a single, unified file system.
|
||||
|
||||
Some example projects:
|
||||
|
||||
[https://github.com/bep/docuapi](https://github.com/bep/docuapi)
|
||||
: 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 directory 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)
|
||||
: A simple site used for testing.
|
||||
@@ -1,27 +1,19 @@
|
||||
---
|
||||
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
|
||||
description: Hugo provides advanced theming support with theme components.
|
||||
categories: []
|
||||
keywords: []
|
||||
weight: 30
|
||||
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:
|
||||
A project can configure a theme as a composite of as many theme components as 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]
|
||||
You can even nest this, and have the theme component itself include theme components in its own `hugo.toml` (theme inheritance).
|
||||
|
||||
The theme definition example above in `hugo.toml` creates a theme with 3 theme components with precedence from left to right.
|
||||
|
||||
@@ -29,17 +21,15 @@ For any given file, data entry, etc., Hugo will look first in the project and th
|
||||
|
||||
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.
|
||||
- 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 directory 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.
|
||||
The name used in the `theme` definition above must match a directory in `/your-site/themes`, e.g. `/your-site/themes/my-shortcodes`.
|
||||
|
||||
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`
|
||||
- `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,20 +1,15 @@
|
||||
---
|
||||
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
|
||||
description: How to use Hugo Modules.
|
||||
categories: []
|
||||
keywords: []
|
||||
weight: 20
|
||||
aliases: [/themes/usage/,/themes/installing/,/installing-and-using-themes/]
|
||||
toc: true
|
||||
---
|
||||
|
||||
## Prerequisite
|
||||
|
||||
{{< gomodules-info >}}
|
||||
{{% include "/_common/gomodules-info.md" %}}
|
||||
|
||||
## Initialize a new module
|
||||
|
||||
@@ -33,15 +28,15 @@ 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>`
|
||||
1. Import the theme:
|
||||
|
||||
{{< code-toggle file=hugo >}}
|
||||
[module]
|
||||
[[module.imports]]
|
||||
path = "github.com/spf13/hyde"
|
||||
{{< /code-toggle >}}
|
||||
{{< 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).
|
||||
Modules will be downloaded and added when you add them as imports to your configuration. See [configure modules](/configuration/module/#imports).
|
||||
|
||||
To update or manage versions, you can use `hugo mod get`.
|
||||
|
||||
@@ -83,7 +78,7 @@ replace github.com/bep/hugotestmods/mypartials => /Users/bep/hugotestmods/mypart
|
||||
|
||||
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.
|
||||
Instead of modifying the `go.mod` files, you can also use the modules configuration [`replacements`](/configuration/module/#top-level-options) option.
|
||||
|
||||
## Print dependency graph
|
||||
|
||||
@@ -111,9 +106,9 @@ Also see the [CLI Doc](/commands/hugo_mod_graph/).
|
||||
|
||||
Note that:
|
||||
|
||||
* You can run `hugo mod vendor` on any level in the module tree.
|
||||
* Vendoring will not store modules stored in your `themes` directory.
|
||||
* 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.
|
||||
- You can run `hugo mod vendor` on any level in the module tree.
|
||||
- Vendoring will not store modules stored in your `themes` directory.
|
||||
- Most commands accept a `--ignoreVendorPaths` flag, which will then not use the vendored modules in `_vendor` for the module paths matching the given [glob](g) pattern.
|
||||
|
||||
Also see the [CLI Doc](/commands/hugo_mod_vendor/).
|
||||
|
||||
@@ -127,7 +122,7 @@ Also see the [CLI Doc](/commands/hugo_mod_clean/).
|
||||
|
||||
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).
|
||||
Note that you can also configure the `modules` cache with a `maxAge`. See [configure caches](/configuration/caches/).
|
||||
|
||||
Also see the [CLI Doc](/commands/hugo_mod_clean/).
|
||||
|
||||
@@ -137,7 +132,7 @@ Workspace support was added in [Go 1.18](https://go.dev/blog/get-familiar-with-w
|
||||
|
||||
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.
|
||||
A workspace can be configured in a `*.work` file and activated with the [module.workspace](/configuration/module/) 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:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user