Regression: `<...>` inside inline code spans in commit subjects still break PR-body parsing, silently skipping a component release (manifest mode)

[eungkyu]

This is a regression / incomplete fix of #1659 (fixed by #1661). HTML tags inside inline code spans in commit subjects are intentionally left unescaped by htmlEscape, but they still break the PR-body re-parsing step, causing a component's release to be silently skipped.

Environment

• release-please 17.6.0 (googleapis/release-please-action@v5)
• Manifest mode, multi-package monorepo, include-component-in-tag: true

Root cause

• src/changelog-notes/default.ts htmlEscape() escapes bare </>, but via the regex /[^`].*[^`]|`[^`]*`|<|>/g with match.length > 1 ? match : ... it leaves </> inside inline code spans untouched. So a subject like add `check --report <path>` keeps a raw <path> in the generated release-PR body.
• On release creation, src/util/pull-request-body.ts extractMultipleReleases() re-parses the PR body with node-html-parser. It does not understand markdown backticks, so <path> is treated as an unclosed HTML tag and the following <details> block(s) get nested inside it and dropped from root.getElementsByTagName('details') — the exact mechanism described in HTML tags in commit messages can break PR message parsing, causing missing package releases #1659.
• src/strategies/base.ts then logs Pull request contains releases, but not for component: <X> and skips that component: no git tag, no GitHub release, no publish — while the workflow still reports success.
• The next release-please run can no longer find that component's release boundary (tag missing) and re-walks its entire history, producing a bogus major bump in the next release PR.

Steps to reproduce

1. In a manifest repo with ≥2 packages, land a commit whose subject contains an inline code span with an HTML-tag-looking token, e.g. feat: add `--report <path>` flag (affecting multiple packages so it appears in multiple <details> blocks).
2. Merge the release PR.
3. Observe that the component carrying the 2nd occurrence is not released (no tag/release/publish), though the run succeeds.

Minimal reproduction

// npm i release-please@17.6.0
const { PullRequestBody } = require('release-please/build/src/util/pull-request-body.js');
const body = [
  ':robot: release', '---', '',
  '<details><summary>pkg-a: 1.0.0</summary>\n\n### Features\n\n* add `--report <path>` flag\n</details>',
  '<details><summary>pkg-b: 2.0.0</summary>\n\n### Features\n\n* add `--report <path>` flag\n</details>',
  '---', 'footer',
].join('\n');

console.log(PullRequestBody.parse(body).releaseData.map(d => d.component));
// => [ 'pkg-a' ]            <-- pkg-b silently dropped

console.log(PullRequestBody.parse(body.replaceAll('<path>', '&lt;path&gt;')).releaseData.map(d => d.component));
// => [ 'pkg-a', 'pkg-b' ]   <-- escaping the angle brackets fixes it

Real-world case: an 11-package release PR dropped exactly the package whose <details> block contained the 2nd <path> occurrence.

Suggested fix

Since the PR body is later HTML-parsed (not rendered as markdown), </> should be escaped even when inside code spans when generating the body. Alternatively, make extractMultipleReleases extract <details> blocks robustly so an unclosed tag in note text cannot corrupt the DOM and drop sibling blocks.

[johnitvn]

Adding a second failure mode of this same gap (raw <...> from inline code spans reaching the release PR body): when the token is itself `<details>`, node-html-parser produces a summary-less <details> element and extractMultipleReleases() dereferences it unconditionally - so instead of silently skipping a component, every subsequent run hard-crashes with:

TypeError: Cannot read properties of undefined (reading 'match')
    at extractMultipleReleases (build/src/util/pull-request-body.js)

Verified present in both 17.6.0 and latest 17.11.1. Full reproduction and stack trace in #2884; proposed defensive fix (skip summary-less blocks, warn, fall back to single-release parsing) in #2885.

[yohimik]

I independently reproduced both parser failures in the exact published release-please@17.11.2 package (Node 24.18.0, installation with lifecycle scripts disabled):

raw <path>:      [ 'pkg-a' ]
escaped <path>:  [ 'pkg-a', 'pkg-b' ]
raw <details>:  TypeError: Cannot read properties of undefined (reading 'match')
escaped control: 1 release

Here is a self-contained parser-only check after npm install --ignore-scripts --save-exact release-please@17.11.2:

const {PullRequestBody} = require('release-please/build/src/util/pull-request-body.js');
const components = body => PullRequestBody.parse(body).releaseData.map(x => x.component);
const body = [
  ':robot: release', '---', '',
  '<details><summary>pkg-a: 1.0.0</summary>\n\n### Features\n\n* add `--report <path>` flag\n</details>',
  '<details><summary>pkg-b: 2.0.0</summary>\n\n### Features\n\n* add `--report <path>` flag\n</details>',
  '---', 'footer'
].join('\n');
console.log(components(body));
console.log(components(body.replaceAll('<path>', '&lt;path&gt;')));
const crash = [
  ':robot: I have created a release *beep* *boop*', '---', '',
  '## [0.9.1](https://github.com/example/repo/compare/v0.9.0...v0.9.1) (2026-08-22)', '',
  '### Bug Fixes', '', '* escape an unbalanced `<details>` tag', '', '---', 'footer'
].join('\n');
try { PullRequestBody.parse(crash); }
catch (e) { console.log(e.name + ': ' + e.message); }
console.log(PullRequestBody.parse(crash.replaceAll('<details>', '&lt;details&gt;')).releaseData.length);

PR #2885 guards the missing-summary crash reported in #2884, but its patch does not change the inline-code escaping involved in the silent component omission here. Keeping both inputs as regression cases would distinguish “does not throw” from “retains the full component set.”

This check calls only PullRequestBody.parse(); it does not execute a complete release or create tags or GitHub releases.