Out-of-the-box highlighting for IEC 61131-3 Structured Text (Prism `iecst`) + a seam to register extra grammars

[andreiyurik]

Use case

We run an open education platform for industrial trades (Rails 8.1, importmap, Action Text + Lexxy). Our PLC programming lessons contain IEC 61131-3 Structured Text (ST) — the standard programming language of industrial automation. Today we mark those blocks as pascal (the conventional alias Rouge uses server-side), but the real language is ST, and highlighted ST samples are core content for this audience, not a nice-to-have.

What happens

The bundled Prism build ships ~20 grammars (bash, c, cpp, go, java, js, json, kotlin, php, python, ruby, rust, sql, swift, ts, xml, …). Neither iecst nor pascal is among them, so an ST code block stays unhighlighted — both live in the editor and in rendered content via the exported highlightCode().

And since the Prism instance isn't exported from the package, an app can't register additional grammars from prismjs on its own — there's no seam to extend the language set.

Why out-of-the-box support matters here

• ST is the lingua franca of PLC programming; industrial/technical education is a real audience for Action Text apps, well beyond web development.
• The people writing these lessons are trade experts, not JS developers. In a no-build importmap app there is no reasonable way for them (or us) to patch a vendored bundle.
• PrismJS already ships an iecst grammar (“Structured Text (IEC 61131-3)”), so bundling it should be a build-config one-liner — and it would appear in the editor's code-language picker too.

Ask

1. Include iecst (and ideally pascal) in the bundled grammar set — first-class, out-of-the-box ST support.
2. Additionally (and more generally): export the Prism instance or a small registerLanguage hook, so apps can load any extra grammar from prismjs themselves.

Happy to send a PR for whichever direction you prefer.

[andreiyurik]

Full grammar plus aliases and dependency declarations — name-only can't serve the main use case, since the whole point is that the grammar isn't in the bundle.

A shape mirroring Prism's own component metadata (components.json: alias, require) would let apps pass grammars straight from prismjs/components:

Lexxy.registerLanguage("iecst", grammar, { aliases: ["pascal", "st"], requires: [] })

• requires lets Lexxy fail loudly (or order registrations) when a base grammar is missing, instead of silently emitting broken tokens for the extend-family grammars (typescript/scss/cpp).
• Aliases matter more than they look: server-side highlighters set fence-tag conventions (Rouge has no iecst, so ST is conventionally tagged pascal), and existing content carries those tags. An alias maps the legacy tag onto the right grammar without rewriting content.
• Registration should write to the shared global registry, be idempotent, and be callable before any editor exists — the exported highlightCode() runs on rendered pages with no editor at all, so the registry can't be tied to editor initialization.
• Agreed on the two-editor test: with a global registry the observable result must be the union of registrations regardless of init order; a duplicate registration with a different grammar should probably warn + last-write-wins.

Having looked at our real content since filing this, I'd also reorder the asks: the seam is the valuable one, bundling is secondary. Our most common code language turns out to be G-code (CNC lessons) — a grammar that exists in no highlighter bundle, Prism upstream included. No amount of bundling covers that class of niche industrial languages; a 20-line hand-written grammar passed through a registration seam does.

Happy to help review, and could draft the PR if the maintainers confirm the direction and preferred signature.