Update dependencies#2167
Merged
Merged
Conversation
`lang` is a reserved Hugo front-matter key that identifies a page's language. Hugo deprecated user-supplied top-level `lang:` in v0.144.0, and per Hugo's automatic deprecation-level schedule (encoded in `common/hugo/hugo.go:deprecationLogLevelFromVersion`) the warning escalates to a build-aborting error once the running Hugo is at least 15 minor releases past the deprecation. v0.155.3, the version currently pinned in `params.hugo_version`, sits 11 releases out and therefore only logs `lang in front matter was deprecated in Hugo v0.144.0 and will be removed in a future release.` as a warning; any Hugo from v0.159.0 onward refuses to build the site, escalating the same condition to `lang in front matter was deprecated in Hugo v0.144.0 and subsequently removed.` as soon as it sees one of the generated translated manual pages. The site already accesses the value through `.Params.lang` (for example in `layouts/partials/ref/category.html` and `layouts/partials/ref/languages.html`), and `.Params` exposes nested `params:` entries identically to root-level user-defined keys. Nesting the value under `params:` therefore preserves all template behavior while making clear that this is a user-defined attribute rather than a Hugo-reserved one. Renaming the key (e.g. to `pagelang`) was considered but would have required touching every template reference for no real gain. This commit only updates the generator. The translated manual pages already checked into `external/docs/content/docs/*/<lang>.html` still carry the old top-level `lang:` and must be regenerated by triggering the `update-translated-manual-pages.yml` workflow with `force-rebuild: true` before the Hugo version pinned in `hugo.yml` can be raised past the warning-to-error boundary. See https://gohugo.io/content-management/multilingual/ for Hugo's current language-handling model. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Updated via the `update-translated-manual-pages.yml` GitHub workflow.
Hugo v0.158.0 deprecated `languageCode` (both the top-level config key
and the per-language `languages.<lang>.languageCode` form) in favor of
`locale`/`languages.<lang>.locale`. v0.161.1 still emits a runtime
warning ("project config key languageCode was deprecated in Hugo
v0.158.0 and will be removed in a future release. Use locale instead.")
on every build, and the upstream discourse thread for the v0.158.0
deprecations announces the eventual removal:
https://discourse.gohugo.io/t/deprecations-in-v0-158-0/56869
`locale: en` is accepted by every Hugo version we still support
(verified against v0.155.3, the version currently pinned in
`params.hugo_version`, where it produces neither a warning nor an
error), so this rename is safe to land independently of the broader
Hugo upgrade.
Assisted-by: Opus 4.7
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Hugo v0.156.0 deprecated `Site.Data` in favor of the new global `hugo.Data` and v0.158.0 deprecated the top-level `languageCode` key that the previous commit migrated to `locale`. The v0.156.0 deprecation discourse thread spells out the rationale and the staged removal plan: https://discourse.gohugo.io/t/deprecations-in-v0-156-0/56732 The `hugo.Data` global was introduced in v0.156.0; v0.155.3 (the version this commit replaces) renders any reference to it as `can't evaluate field Data in type interface {}` and aborts the build. The template migration must therefore land together with the `params.hugo_version` bump rather than as a preparatory commit. Several other changes between v0.155.3 and v0.161.1 were inspected and found inert for this site. The v0.144.0 deprecation of top-level `lang:` in front matter was addressed by `script/update-docs.rb` switching to `params.lang` and the subsequent `Update translated manual pages` regeneration commit. The v0.161.0 hardening of `security.http.urls` and the new `--permission` requirement for Node-based asset pipelines (PostCSS, Babel, Tailwind) do not bite us because the layouts call `resources.GetRemote` nowhere and invoke none of the affected Node tools. Finally, the template functions removed in v0.156.0 (`data.GetCSV`, `data.GetJSON`, `crypto.FNV32a`, `resources.Babel`, `resources.PostCSS`) and the language methods deprecated in v0.158.0 (`.Site.LanguageCode`, `.Language.LanguageName`, `.Language.LanguageDirection`) are not referenced anywhere under `layouts/`. The site was built locally with the new Hugo against the regenerated external content; the build now completes without any deprecation warnings or errors, and the rendered pages differ from the v0.155.3 baseline only in stylesheet content hashes. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
v1.5.0 (https://github.com/CloudCannon/pagefind/releases/tag/v1.5.0) is the first stable release in the 1.5 line; it overhauls ranking and indexing without breaking the existing Default UI consumed by `layouts/_default/baseof.html` (the upstream notes are explicit that "the existing Default UI and Modular UI remain available and supported for now"). The new metadata-aware ranking even improves the `commit`/`config`/`log`/`rev-parse` checks that the CI workflow runs via `script/run-pagefind.js`: each query now puts the corresponding `/docs/git-X.html` page in first position with a much larger gap to the runner-up than before, because page titles are weighted into the score (verified locally with the same script that CI runs). v1.5.2 (https://github.com/CloudCannon/pagefind/releases/tag/v1.5.2) is a Linux-only fix that swaps in jemalloc on the musl build to recover the 2x indexing speedup that v1.5.0 otherwise regresses on Linux. It is the version that should actually be pinned for our CI runners: Pagefind only ships musl Linux binaries (the GitHub release assets contain no `*-unknown-linux-gnu` archives) and the `npx pagefind` install on `ubuntu-latest` resolves to `@pagefind/linux-x64`, which wraps that musl binary. The `npx -y pagefind@${PAGEFIND_VERSION} --site public --write-playground` invocation in `.github/workflows/ci.yml` and in the `deploy-to-github-pages` composite action continues to work unchanged: `--write-playground` is supported by both 1.4.0 and 1.5.2 (verified locally via `pagefind --help`), and the playground HTML/JS/CSS still land at `public/pagefind/playground/`. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
`@playwright/test` ^1.47.2 -> ^1.60.0 captures roughly a year of patch and minor releases since the existing pin landed (see the upstream notes for 1.48 through 1.60 at https://github.com/microsoft/playwright/releases). The constraint stays in the v1 range, where Playwright maintains stable browser APIs; nothing in `tests/git-scm.spec.js` exercises behavior that changed in any of the intervening releases. `@types/node` ^22.5.4 -> ^22.19.19 stays inside the Node 22 LTS typings line. The repository contains no `*.ts` files and no `tsconfig.json`; this package only powers editor tooling for the plain-JavaScript helpers under `script/` and `tests/`. A jump to v24 or v25 is therefore avoided for now: it would describe APIs that the runtime LTS does not yet ship, with no offsetting benefit. `node-html-parser` ^7.0.1 -> ^7.1.0 (see https://github.com/taoqf/node-html-parser/releases/tag/v7.1.0) stays in the v7 line and is verified to keep `script/graphviz-ssr.js` working: `parse('<div>hi</div>').toString()` round-trips correctly under the new release. `npm install` was rerun locally and resolves the three packages to 1.60.0, 22.19.19 and 7.1.0 respectively. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
`.github/workflows/ci.yml` and the `deploy-to-github-pages` composite action both already pin `actions/setup-node@v5`. The standalone Playwright workflow was the only place still on `@v4`, presumably just because it predates the bump that moved the rest of the repo forward. `@v5` accepts the same `node-version: lts/*` input the workflow already passes (the input set is unchanged across the v4 -> v5 boundary; see https://github.com/actions/setup-node/releases/tag/v5.0.0 ), so this is a pure cleanup with no behavior change beyond using the action runtime that the rest of the repository has already standardised on. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
force-pushed
the
update-dependencies
branch
from
69e4615 to
480a853
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Changes
Context
It's always hard to upgrade e.g. Hugo after letting things slide for too long. Here, for example, we had to take care of a deprecated front-matter attribute, among other things.