jmooring/hvm v0.14.0

on GitHub

Release notes

Hugo provides four build editions: standard, withdeploy, extended, and extended_withdeploy. Previous versions of hvm exclusively downloaded the extended edition. This release allows you to choose both the version and the edition.

What changed

File format

The .hvm file now stores a version and edition pair, replacing the previous format that only stored a version. For example:

v0.159.2/standard
v0.159.2/withdeploy
v0.159.2/extended
v0.159.2/extended_withdeploy

Command behavior

The hvm use and hvm install commands now handle editions in two ways, depending on how you call them.

When you provide a version as an argument, you can now optionally append an edition.

• If you provide the version only and omit the edition, hvm follows the promptForEdition setting to either prompt you for a choice or automatically select your defaultEdition.
• If you provide both the version and the edition, hvm selects that specific pair immediately.

When you run hvm use or hvm install without any arguments, the tool starts an interactive flow.

• In step 1, you select a version from the list.
• In step 2, hvm displays a second menu to select an edition if promptForEdition is true.
• If promptForEdition is set to false, hvm automatically selects the defaultEdition for the version you chose in the first step.

Cache layout change

We changed the cache directory structure from something like this:

hvm/
├── default/
│   └── hugo
├── v0.150.0/
│   └── hugo
└── v0.159.2/
    └── hugo

to something like this:

hvm/
├── default/
│   └── hugo
├── v0.150.0/
│   ├── extended/
│   │   └── hugo
│   └── standard/
│       └── hugo
├── v0.159.2/
│   ├── extended/
│   │   └── hugo
│   ├── standard/
│   │   └── hugo
│   └── withdeploy/
│       └── hugo
├── releases.json
└── schema.json

Cache schema versioning

With this and future releases, hvm creates a schema.json file at the root of the cache directory. On the first run after upgrading, hvm will not find a schema.json in the cache directory, so it removes all previously cached version directories and writes a new schema.json file. A message printed to stderr will state that hvm migrated the cache to a new format and removed old cached versions. This migration does not affect the default directory used by hvm install.

New configuration options

There are two new configuration keys.

• defaultEdition (string)

  The edition hvm use and hvm install select when promptForEdition is false or when you omit the edition during direct selection. The default is standard.

• promptForEdition (bool)

  Whether hvm use and hvm install show the edition selection menu during interactive selection or when you omit the edition during direct selection. Setting this to false instructs hvm to select the defaultEdition instead. The default is true.

Why we changed it

Hugo will deprecate the extended and extended/deploy editions in the near future, requiring users to migrate to other editions. Tracking the edition explicitly is now a requirement for hvm so that shell integration can locate the correct binary in the two-level cache hierarchy.

Historically, users installed one of the extended editions to enable specific features that other editions lacked, but these requirements are now obsolete:

• Users previously required the extended editions to encode WebP images. This is no longer necessary because all editions now handle WebP encoding natively.
• Users previously required the extended editions to transpile Sass to CSS using LibSass. However, the Sass team deprecated LibSass six years ago. Users should now use Dart Sass, which is compatible with every Hugo edition.

Breaking changes

1. We changed the cache directory structure to accommodate the version and edition identity. Tracking this structure now involves a schema file, and any schema changes trigger a cache clearing to prevent the accumulation of obsolete data. Consequently, the first time you run hvm after installing this release, it will clear your existing cache to ensure you do not have unnecessary files lying around.
2. We changed the .hvm file format. On the first read, hvm migrates files containing only a version automatically. Specifically, hvm migrates versions at or below v0.159.2 to version/extended, while it migrates later versions to version/defaultEdition. After printing a warning to stderr, hvm rewrites the file in the new format. You do not need to take any manual action.
3. You must update custom scripts that manually parse the .hvm file. Because the file now contains a version and edition pair separated by a forward slash, existing logic that expects only a version string will no longer function as expected.

Shell integration

Official shell integration scripts continue to function without modification. While we changed the internal pathing to the binary to include the edition component, the scripts handle this resolution automatically. You do not need to update your shell configuration manually.

Changelog

• 72d396f all: Add edition selection alongside version selection
• 3319350 all: Improve test coverage
• 691d141 build(deps): bump github.com/pelletier/go-toml/v2 from 2.2.4 to 2.3.0
• 0bc709a build(deps): bump golang.org/x/mod from 0.33.0 to 0.34.0
• f0a6ac3 build(deps): bump golang.org/x/oauth2 from 0.35.0 to 0.36.0
• 3246351 cmd/aliases: Improve PowerShell alias
• 033fa5d cmd/aliases: Use Write-Host for powershell alias output
• f7c4a5b cmd: Remove unused helper function
• a71c740 misc: Adjust badges
• 4189932 misc: Fix coverage badge
• 887b03f misc: Remove coverage badge
• c233050 misc: Update README
• 3cbb303 misc: Update README
• 8a386c0 misc: Update README
• ae84cea misc: Update deps