Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Hugo 0.141.0 introduced a new
try
function, replacing the way errorhandling is done. Update the affected render hooks and shortcodes such
that they no longer break on Hugo 0.141.0 and above.
Basic example
See gohugoio/hugo#13216 for migration instructions and further details.
Motivation
New users of this theme are likely to use the latest version of
Hugo--ensure the build does not break for those.
Our CI (and probably most of other automated Hugo builds) is set to
always use the latest extended version of Hugo. Without this change,
we'd have to pin it to 0.140.2 or below.
Checks
npm run test
(if relevant)Some further remarks, which I wish to fully resolve before landing this
change. We can downgrade Hugo in our CI for the meantime.
Should we bump the minimum Hugo version in the affected files? I'm
seeing a minimum of 0.114.0 at the moment, checked individually.
Alternatively, should we just introduce a safeguard around the affected
block of code, checking if we are required to use
try
and do soconditionally, based on the Hugo version in use?
Personally I'm leaning towards not touching that minimum version, and
instead wrap the affected blocks in a new safeguard. That way, we can
comfortably cut a patch-level release and not worry about a
(technically) breaking change. Please let me know what you think.