New in v0.150.0

If set to a version query, this import becomes a direct dependency, in contrast to dependencies managed by Go Modules. See this issue for more information.

Fixes #13964

Notes

• version can be blank or set to a Go Module version query. It's recommended to stick to tagged version values following Go Modules version numbering scheme, e.g. v1.0.0. This enables module caching and you avoid having to download the module every time you run hugo. Also see module vendoring.
• If version is set, we call it a direct dependency, in contrast to dependencies managed by Go Modules.
• With only direct dependencies (including its transitive dependencies), you don't need a go.mod. For transitive dependencies, see noimports.
• You can import the same path multiple times with different values of version, but you need to think about how to mount the different versions into your project. But note that in the first version of this new feature you can only have one import per resolved version of a given path, but each import can have multiple mount definitions. Also see the [nomounts].(gohugo.io/configuration/module#nomounts) config setting.
• The command hugo mod get will only work on module imports without a version set, so for these you either need to edit the config file or set a loose version query (e.g. main, latest, >v1.0.0) . Note that Go Module's Minimum Version Selection (MVS) is not relevant for these imports.

TODOs

• vendoring with hugo mod vendor.
• go.sum; imports with version set will not en up in go.{mod,sum}. The first can be a good thing (because you don't need a go.mod file for simpler setups). But without a sum entry, we don't get the security it gives, which I think is worth going the extra mile. I think that the tooling for this should be relatively straight forward and that we could create an extra hugo.direct.sum (Make hugo.mod the new go.mod #13971 will give us a hugo.sum) file for these entries).
• Decide how the path printed in go mod graph, hugo config mounts, vendor.txt should look like this; I think the pattern I currently use for vendoring will be OK and give the most flexibility re. --ignoreVendorPaths matching and would make it unique. See example below.
• Add some tests.

Sample vendor.txt:

# github.com/bep/hugo-mod-misc/dummy-content v0.3.0
# github.com/bep/hugo-mod-misc/dummy-content@v0.1.0 v0.1.0
# github.com/bep/hugo-mod-misc/dummy-content@v0.2.0 v0.2.0

The entries resolved via a version in config have a pseudo path constructed with [path]@[resolved version].

disableInlineImports

(bool) Whether to disable inlining of @import statements. Inlining is performed recursively, but currently once only per file. It is not possible to import the same file in different scopes (root, media query, etc.). Note that this import routine does not care about the CSS specification, so you can have @import statements anywhere in the file. Default is false.

skipInlineImportsNotFound

(bool) Whether to allow the build process to continue despite unresolved import statements, preserving the original import declarations. It is important to note that the inline importer does not process URL-based imports or those with media queries, and these will remain unaltered even when this option is disabled. Default is false.