Docs site: 17 Dependabot alerts blocked behind a vuepress upgrade that OOMs the docs build

The problem

17 Dependabot alerts are open against doc/vuepress/package-lock.json — 13 × vite, 3 × js-yaml, 1 × esbuild — and none of them can be fixed on their own.

package.json exact-pins vuepress while caret-ranging its plugins, so vuepress-plugin-search-pro floats to rc.59, whose peer is [email protected]:

Found: [email protected]                    (exact pin, root devDependency)
Could not resolve: peer [email protected]   from [email protected]

npm audit fix aborts with ERESOLVE. That is why Dependabot — which is enabled here and has merged 16+ other PRs against this same directory — left exactly these behind. Clearing them requires moving the whole vuepress stack at once.

How urgent this is: not very

Everything here is scope=development. This tree only builds the documentation site in ci/doc.sh and ships in no released espnet artifact, so none of these are reachable by anyone installing the package. Please do not treat this as a security emergency — it is dependency hygiene, and the reason it is worth doing is that the pins keep drifting further out of date, not that users are exposed.

The nanoid alerts from the same tree were fixed separately in #6640.

What is already done

Branch fix/vuepress-rc31-upgrade (kept, please do not delete) — see #6641 for the full write-up.

The dependency work is complete and verified:

@vuepress/bundler-vite      2.0.0-rc.14  -> 2.0.0-rc.31
vuepress                    2.0.0-rc.14  -> 2.0.0-rc.31
vuepress-theme-hope         2.0.0-rc.51  -> 2.0.0-rc.109
vuepress-plugin-search-pro  ^2.0.0-rc.51 -> removed, replaced by @vuepress/plugin-slimsearch 2.0.0-rc.134
vue                         ^3.4.31      -> ^3.5.40
sass-embedded                            -> ^1.104.0

• npm audit: 0 vulnerabilities (from 36). All 17 alerts would close.
• The lockfile regenerates byte-identically from package.json alone.
• theme.ts typechecks clean, with four rc.109 never options migrated (searchPro → plugins.slimsearch, iconAssets → plugins.icon.assets, plugins.mdEnhance → top-level markdown, markdown.codetabs → codeTabs).

search-pro is replaced rather than bumped because its own latest still peers on rc.18; slimsearch is its successor and theme-hope rc.109 types plugins.searchPro as never.

What blocks it

The docs build runs out of memory. Rendering 1856 pages overran node's default ~4 GB heap; raising it to 8 GB still OOMs at ~7950 MB (exit 134). master builds the same content fine inside the default 4 GB, so the rc.31 stack needs >2× the memory — but the cause is not identified.

Two plausible explanations were tested and both failed:

• Restricting shiki's languages: no effect. A/B on an identical corpus — restricted 2.61 GB, unrestricted 2.38 GB. shiki 4 already lazy-loads only the languages it encounters, so shortening langs cannot help.
• Switching to prismjs: no effect on memory. It OOMs at the same corpus weight. It is substantially faster (337s → 152s on a heavy corpus), which may be independently interesting, but it does not solve this.

Synthetic corpora (1856 pages, varying code-block density) turned out not to model the real docs at all: at the weight where they discriminate, master is worse than the branch — more memory, slower. So whatever pushes the real build past 8 GB is a property of the actual generated content, not of page count or code-block volume.

Where to start

1. Cheapest probe: one CI run with NODE_OPTIONS=--max-old-space-size=14336 (runners have 16 GB). If it passes, the requirement is known and this becomes a trade-off decision instead of a mystery. If it fails, the upgrade has a deeper problem and that is worth knowing early.
2. Proper reproduction: run ci/install.sh then ci/doc.sh locally to get the real generated content — the sphinx API reference, the espnet/notebook clone through nbconvert, and the converted recipe READMEs. Nobody has done this yet; it is the only way to profile the actual build (node --cpu-prof / --heap-prof).
3. Note for whoever picks this up: any PR touching the docs site needs the Documentation label, or generate_and_deploy_doc skips on pull requests and the build goes unverified until it hits master.

Unrelated but worth fixing

master's doc/vuepress/src/.vuepress/theme.ts has two type errors today: the existing searchPro: searchProPlugin({ placeholder: … }) passes a PluginFunction where the theme expects an options object, and placeholder is not a valid search-pro option. Nothing typechecks the docs config in CI, so these have never surfaced. Adding a tsc --noEmit step for doc/vuepress would catch this class of problem before it reaches a build.