feat: Redoc v3.0.0

[AlexVarchuk]

What/Why/How?

Redoc v3.0.0 release:

• Modern UI
• New Search Functionality
• Native Dark Theme Support
• Deep CSS Variable Customisation

Reference

Tests

Screenshots (optional)

## Check yourself

• Code is linted
• Tested
• All new/updated code is covered with tests

To fix the problem, we need to properly escape all RegExp meta-characters (especially backslashes) in headerId before embedding it in a RegExp constructor.

• The best way to do this is to use a utility function that escapes all RegExp meta-characters in a string (not just forward slashes).
• One reliable approach is to use an external, well-tested library (such as escape-string-regexp), but if that's not available or allowed, we can define a simple, robust internal utility to escape RegExp special characters ([-\/\\^$*+?.()|[\]{}]).
• Implement such a function (e.g., escapeRegExp) within this file, and use it on headerId before interpolation into the RegExp constructor.

Edit details:

• Add an escapeRegExp function at the top or inside the class.
• Replace the call to headerId.replace(/\//g, '\\/') in line 60 with escapeRegExp(headerId).
• No new imports are required; implement the utility inline.

---

To fix the unescaping order in the unescapeHTMLChars function, we need to modify the sequence of .replace operations so that & is unescaped last. This prevents " from becoming " (and then ") in a single pass, preserving correct character decoding and output. Only lines within this function (lines 154–158) need editing. No extra dependencies or imports are needed; we simply rearrange the .replace calls.

To fix the problem, we should ensure that user-supplied input is not used directly as a format string argument in logging functions. Instead, the safest and most standard approach is to use a format string with only safe, non-user origins (such as a literal string like "Decoding failed: %s") and pass the user-controlled value as a second argument. Therefore, in console.error(Decoding failed: ${str}, e);, change this to console.error("Decoding failed: %s", str, e); on line 46 of src/utils/string.ts. This way, format tokens in user input cannot interfere with the formatting of the log call.

No new imports or definitions are needed. Only a change in the way the log line is constructed.

---

To fix this issue without altering the functional output, ensure untrusted data never controls the format string in a logging statement with multiple arguments. That is, rather than interpolating user data into the string with a template literal, use the %s format and pass the untrusted string as a separate argument. This ensures the log printing remains predictable and safe regardless of input. Specifically, change
console.error(`Invalid URL: ${processedUrl}`, error);
to
console.error('Invalid URL: %s', processedUrl, error);
in src/utils/url.ts (inside the catch block at line 12).

The best way to fix this problem is to add an explicit permissions block to your workflow, either at the workflow root or for each job, specifying the least privileges required to successfully complete the actions. As a minimum starting point (per CodeQL suggestion), set contents: read at the root level. If individual jobs need greater permissions (e.g., to create GitHub releases, modify contents, or open pull requests), add a permissions section specifying those details for each job. To implement this, uncomment and adjust the permissions section at the top of the workflow file (.github/workflows/release.yml), right below name: Release. If you're unsure which permissions are necessary for each job, start with contents: read at the root.

• General approach:
  To fix the issue, set an explicit permissions block at the workflow level (root), which applies to all jobs unless overridden. If a job requires more than the minimal permissions, add a more permissive block at that job. Typically, start with contents: read and add others as required (e.g., id-token: write for OIDC, pull-requests: write for PR operations).

• Best way to fix for this workflow:
  Uncomment and apply the permissions block at the top/root of the workflow (lines 3–5), so all jobs run with the explicit permissions of id-token: write and contents: read. This covers most modern workflows for releases, including publish to npm or S3 using OIDC. If further jobs need more permissions, define them at the job level, but for the provided code it does not appear necessary.

  • Uncomment lines 3–5 so the root-level permissions block is active.

• Files/Regions to change:
  Only .github/workflows/release.yml lines 3–5.
  No new imports, code, or methods are required.

To address this issue, we need to add a permissions block to the publish-cdn job to ensure that the job runs with minimal privileges. Review of the steps in this job shows that none of them require write access to the repository or other resources; only reading repository contents (to check out code, etc) is necessary. Therefore, setting permissions: contents: read (the minimal recommended value) is sufficient. The update must be made to the publish-cdn job definition in .github/workflows/release.yml, under jobs.publish-cdn. No imports or other structural changes are necessary.

---

The problem should be fixed by adding a permissions block to the invalidate-cache job starting at line 73. As a starting point, {contents: read} is sufficient since this job checks out the code and does not appear to need to write or modify repository contents, pull requests, or any other privileged resources. Add the following under the job beginning with name: Clear cache, i.e., line 74:

permissions:
  contents: read

No other changes, imports, or dependencies are needed, and no steps or functionality will change.

---