RELEASES

NPM Pack

Featured Image for NPM Pack

Hugo 0.75.0 brings several improvements to Hugo Modules, a new CLI command to bridge the JavaScript dependencies into Hugo, a refresh of the versions of the most important upstream dependencies, and more. There are also some good bug fixes in this release. One notable one is covered by this commit – which covers a “stale content scenario in server” when you include content or page data via GetPage from a shortcode.

NPM Pack

The new CLI command is called hugo mod npm pack. We have marked it as experimental. It works great, go ahead and use it, but we need to test this out in real projects to get a feel of it; it is likely that it will change/improve in the upcoming versions of Hugo. The command creates a consolidated package.json from the project and all of its theme components. On version conflicts, the version closest to the project is selected. We may revise that strategy in the future (minimal version selection maybe?), but this should give both control and the least amount of surprise for the site owner.

So, why did we do this? JavaScript is often a background actor in a Hugo project, and it doesn’t make sense to publish it to a NPM registry. The JS dependencies are mostly build tools (PostCSS, TailwindCSS, Babel), devDependencies. This has been working fine as long as you kept the JS config files (including package.json) in the project, adding duplication/work when using ready-to-use theme components. These tools work best when you have everything below a single file tree, which is very much different to how Hugo Modules work. An example of a module with TailwindCSS:

tailwind-module
├── assets
│   └── css
├── package.json
├── postcss.config.js
└── tailwind.config.js

If you included tailwind-module in a Hugo project and processed it with PostCSS, this is what happened in earlier versions:

  • It used the directory where the postcss.config.js lives as a starting point to look for any require’d dependency.
  • TailwindCSS would, on the other hand, load its configuration file relative to where PostCSS was invoked (the project directory).

The above just doesn’t work and here is the technical notes on how we have fixed this:

  • The new hugo mod npm pack creates a consolidated package.json based on files named package.hugo.json it finds in the dependency tree (one is created for you the first time you run this command). The end result will always be package.json, which works seamlessly with npm install invoked automatically by Netlify and other CI vendors.
  • The main project’s node_modules folder is added to NODE_PATH when running PostCSSand Babel.
  • We have introduced a new mount point assets/_jsconfig where we, by default, mount the JS configuration files that we’re interested in. This is where Hugo will start looking for these files, and the files’ filenames will also be available in the Node environment, so you can do:
let tailwindConfig = process.env.HUGO_FILE_TAILWIND_CONFIG_JS || './tailwind.config.js';
const tailwind = require('tailwindcss')(tailwindConfig);

Module Enhancements

  • We have added a noVendor Glob pattern config to the module config d4611c43 @bep #7647. This allows you to only vendor a subset of your dependencies.
  • We have added ignoreImports option to module imports config 20af9a07 @bep #7646, which allows you to import a module and load its config, but not follow its imports.
  • We have deprecated --ignoreVendor in favour of a --ignoreVendorPaths, a patch matching Glob pattern 9a1e6d15 @bep. A typical use for this would be when you have vendored your dependencies, but want to edit one of them.

Statistics

This release represents 79 contributions by 19 contributors to the main Hugo code base. @bep leads the Hugo development with a significant amount of contributions, but also a big shoutout to @dependabot[bot], @moorereason, and @jmooring for their ongoing contributions. And a big thanks to @digitalcraftsman for his relentless work on keeping the themes site in pristine condition and to @davidsneighbour, @coliff and @kaushalmodi for all the great work on the documentation site.

Many have also been busy writing and fixing the documentation in hugoDocs, which has received 24 contributions by 15 contributors. A special thanks to @jmooring, @bep, @jornane, and @inwardmovement for their work on the documentation site.

Hugo now has:

Notes

  • We now build with Go 1.15, which means that we no longer build release binaries for MacOS 32-bit.
  • You may now get an error message about “error calling partial: partials that returns a value needs a non-zero argument.”. This error situation was not caught earlier, and comes from a limitation in Go’s templates: If you use the return keyword in a partial, the argument you pass to that partial (e.g. the “.”) cannot be zero (and 0 and "" is considered a zero argument).

Enhancements

Templates

Output

Other

Fixes

Other

Last Update: September 14, 2020
Improve this page