Merge commit 'b9bd35d72e14932fb6588ff62b90cddef0a060fc' as 'docs'

This commit is contained in:
Bjørn Erik Pedersen
2019-10-21 10:22:28 +02:00
735 changed files with 38220 additions and 0 deletions

View File

@@ -0,0 +1,32 @@
---
title: Hugo Modules
linktitle: Hugo Modules Overview
description: How to use Hugo Modules.
date: 2017-02-01
publishdate: 2017-02-01
menu:
docs:
parent: "modules"
weight: 01
weight: 01
sections_weight: 01
categories: [hugo modules]
keywords: [themes,modules]
draft: false
aliases: [/themes/overview/,/themes/]
toc: true
---
**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 is 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://blog.golang.org/using-go-modules](https://blog.golang.org/using-go-modules)
This is all very much brand new and there are only a few example projects around:
- [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 Hugos 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.

View File

@@ -0,0 +1,132 @@
---
title: Configure Modules
linktitle: Configure Modules
description: This page describes the configuration options for a module.
date: 2019-07-24
categories: [hugo modules]
keywords: [themes, source, organization, directories]
menu:
docs:
parent: "modules"
weight: 10
weight: 10
sections_weight: 10
toc: true
---
## Module Config: Top level
{{< code-toggle file="config">}}
[module]
proxy = "direct"
noProxy = "none"
private = "*.*"
{{< /code-toggle >}}
proxy
: Defines the proxy server to use to download remote modules. Default is `direct`, which means "git clone" and similar.
noProxy
: Comma separated glob list matching paths that should not use the proxy configured above.
private
: Comma separated glob list matching paths that should be treated as private.
Note that the above terms maps directly to their counterparts in Go Modules. Some of these setting may be natural to set as OS environvent variables. To set the proxy server to use, as an example:
```
env HUGO_MODULE_PROXY=https://proxy.example.org hugo
```
{{< gomodules-info >}}
## Module Config: 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="config">}}
[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 Config: imports
{{< code-toggle file="config">}}
[module]
[[module.imports]]
path = "github.com/gohugoio/hugoTestModules1_linux/modh1_2_1v"
ignoreConfig = 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. `config.toml`, will not be loaded. Note that this will also stop the loading of any transitive module dependencies.
disable
: Set to `true` to disable the module off while keeping any version info in the `go.*` files.
{{< gomodules-info >}}
## Module Config: mounts
{{% note %}}
When the `mounts` config was introduced in Hugo 0.56.0, we were careful to preserve the existing `staticDir` and similar configuration to make sure all existing sites just continued to work.
But you should not have both. So if you add a `mounts` section you should make it complete and remove the old `staticDir` etc. settings.
{{% /note %}}
{{< code-toggle file="config">}}
[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.

View File

@@ -0,0 +1,54 @@
---
title: Theme Components
linktitle: Theme Components
description: Hugo provides advanced theming support with Theme Components.
date: 2017-02-01
categories: [hugo modules]
keywords: [themes, theme, source, organization, directories]
menu:
docs:
parent: "modules"
weight: 50
weight: 50
sections_weight: 50
draft: false
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="config">}}
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 `config.toml` (theme inheritance).[^1]
The theme definition example above in `config.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-shortcode`, `base-theme`, and lastly `hyde`.
Hugo uses two different algorithms to merge the filesystems, 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. `config.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 param/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`

View File

@@ -0,0 +1,122 @@
---
title: Use Hugo Modules
linktitle: Use Hugo Modules
description: How to use Hugo Modules to build and manage your site.
date: 2019-07-24
categories: [hugo modules]
keywords: [install, themes, source, organization, directories,usage,modules]
menu:
docs:
parent: "modules"
weight: 20
weight: 20
sections_weight: 20
draft: false
aliases: [/themes/usage/,/themes/installing/,/installing-and-using-themes/]
toc: true
---
## Prerequisites
{{% 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.:
```bash
hugo mod init github.com/gohugoio/myShortcodes
```
Also see the [CLI Doc](/commands/hugo_mod_init/).
## Update Modules
Modules will be downloaded and added when you add them as imports to your configuration, see [Module Imports](/hugo-modules/configuration/#module-config-imports).
To update or manage versions, you can use `hugo mod get`.
Some examples:
### Update All Modules
```bash
hugo mod get -u
```
### Update One Module
```bash
hugo mod get -u github.com/gohugoio/myShortcodes
```
### Get a Specific Version
```bash
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`:
```bash
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.
## 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.:
```
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 depencies 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 `--ignoreVendor` flag, which will then run as if the none of the `_vendor` folders in the module tree existed.
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](/configuration/#configure-file-caches).
Also see the [CLI Doc](/commands/hugo_mod_clean/).