Normalize common fenced-language aliases for highlight.js lazy loading

[Copilot]

Code fences using short aliases (notably ts/js) were treated as unknown after language lazy-loading, so they skipped syntax highlighting while canonical names still worked. This PR restores alias normalization before loader resolution so aliases and canonical IDs behave identically.

• Root cause

  • The lazy loader resolves modules by canonical language IDs, but alias coverage in the local normalization map was incomplete (sh only), so language-ts / language-js never resolved to loadable modules.

• Change: alias normalization coverage

  • Extended the existing alias→canonical map used by ensureLanguage():
    • ts -> typescript
    • js -> javascript
    • py -> python
    • rb -> ruby
  • Kept behavior scoped to the existing normalization path (no new highlighting mechanism).

• Change: regression coverage

  • Expanded highlight tests to assert alias/canonical equivalence for loading and highlighted output on code blocks.
  • Added coverage for sh, js, ts, py, and rb.

• Change: release note

  • Added a changelog entry under docs/changelog/ describing restored alias handling for code-fence highlighting.

const languageAliases: Record<string, string> = {
  js: 'javascript',
  py: 'python',
  rb: 'ruby',
  sh: 'shell',
  ts: 'typescript',
}

Original prompt

Summary

The website docs-builder is treating certain code fence language aliases like ts and js as unknown, causing syntax highlighting to fail. Using the full language names (typescript, javascript) works. We need a PR that restores/normalizes common aliases to their canonical language IDs so code fences like ts and js get highlighted.

Background / context

A Slack thread reproduced the issue with the Kibana docs where ts (TypeScript alias) doesn't highlight while typescript does. It looks like other aliases such as js may also be affected. Possible recent change: #3692

Reproduction steps

1. On a docs site built with docs-builder, create or find a markdown code fence using an alias, e.g.:

const x: number = 1;

2. Build the docs and view the page in the browser.
3. Observe: code block is not highlighted when ts is used but is highlighted when typescript is used.

Expected behavior

• Recognize common language aliases (at minimum: ts -> typescript, js -> javascript) and apply syntax highlighting equivalently to their canonical names.

Task for the coding agent (make these changes and open a PR):

1. Investigate the repo to find where code block language identifiers are normalized or passed to the syntax highlighter. Likely places:

   • Any language/alias mapping tables or utilities (eg. files named languageMap, aliases, highlight config)
   • The code that prepares code blocks before sending them to the highlighter
   • Recent changes introduced by PR 3692

2. Implement a small normalization layer that maps common aliases to canonical language IDs before invoking the syntax highlighter. At minimum include:

   • ts -> typescript
   • js -> javascript
   • Consider adding other common aliases (e.g., py -> python, rb -> ruby) where appropriate.

3. Add unit tests that verify alias mapping works and that code blocks with aliases produce the same highlight output (or at least the same normalized language id) as canonical names.

4. Run the test suite and update any snapshots if necessary.

5. Include a clear PR description that references this issue, the Slack context, and the root cause if discovered (link to PR 3692 if relevant). Keep the change minimal and well-tested.

Acceptance criteria

• Code fences using ts and js are highlighted after the change (verified locally by the agent's tests and a smoke test).
• Unit tests added/updated to cover alias normalization.
• PR includes a short changelog entry and references the Slack thread and/or PR 3692 if it was the cause.

Notes / constraints

• Do not add any assignees in the PR body. Keep the change scoped to normalization and tests.
• If the repository uses a specific highlighter that already supports aliases, prefer adding aliases in the configuration rather than adding extra runtime logic.
• If you find more affected aliases during investigation, include them and update tests accordingly.

Links referenced

• Slack thread (context only): not attached here
• Possible related PR: Assets: Lazy-load OTel and highlight.js languages #3692

Please open the PR on elastic/docs-builder that implements the fix and include tests and a descriptive PR body.

This pull request was created from Copilot chat.

[shainaraskas]

@copilot we need more languages here. at least html is also broken

Broken aliases actually used in docs-content / elasticsearch / kibana:

• js
• jsx
• ts
• tsx
• text
• txt
• py
• html
• yml
• jsonc
• md
• cmd

[Copilot]

Updated in 6229ed5.

Added alias normalization for the requested set: js, jsx, ts, tsx, text, txt, py, html, yml, jsonc, md, cmd (plus existing sh/rb), and expanded hljs.test.ts to verify alias→canonical resolution and highlighted output for each.

[shainaraskas]

wonder if maintaining this separate list will lead to drift / silent bugs in future, but not sure how to fix

[Copilot]

@copilot I already threw cursor at this but I can let github take a swing ⚾
Ah, sorry! Let's if GH works first, it just recovered from a severe bout of NotEnoughCredititis.
Good boyo....

I can’t create repo issues from this execution environment (GitHub API permission is blocked here). Please create one and I can add a proposed title/body if useful.

[reakaleek]

Closing in favour of #3724