[IDEA] Publish parser and wikitext-serialize as standalone npm packages

[linonetwo]

Is your idea related to a problem? Please describe.

The WikiText parser (core/modules/parsers/wikiparser/) and the wikitext-serialize plugin are tightly coupled to the full TiddlyWiki boot runtime. Third-party tools (editors, linters, content pipelines) that only need to parse or round-trip WikiText must boot a complete $tw environment — including CLI arg parsing and filesystem scanning — just to call wiki.parseText() or serializeWikitextParseTree().

Describe the solution you'd like

Expose the parser and wikitext-serialize functionality as importable packages without requiring the full runtime. Source files in core/ and plugins/ stay as-is; an additional build step generates ESM output from the existing source.

Three publishing surfaces are worth exploring (final decision left to maintainers):

• A. Sub-path exports — add an "exports" field to package.json mapping tiddlywiki/parser and tiddlywiki/wikitext-serialize to generated ESM entry points.
• B. ESM registry files in the existing package — during the TiddlyWiki build, generate static *-registry.mjs files (one per module-type: parser, wikirule, wikiruleserializer) as explicit ESM entry points alongside the existing CJS boot.
• C. Separate scoped packages — publish @tiddlywiki/parser and @tiddlywiki/wikitext-serialize as independent packages produced by a build-time transform.

Describe alternatives you've considered

• Documenting a "minimal boot" recipe — works in Node.js today but carries CLI side-effects and is unusable in browser contexts without bundler workarounds.
• Shipping the full TiddlyWiki as a browser library — too large for tools that only need parsing.

Additional context

• The main blocker is that $tw.modules.forEachModuleOfType (used to discover wikirule and wikiruleserializer modules) requires a fully booted runtime. A static registry generated at build time would replace this, with no change to the existing plugin-tiddler architecture.
• wikitext-serialize is currently STABILITY_1_EXPERIMENTAL and is not included in any default edition.
• The ProseMirror plugin already declares wikitext-serialize as a dependency, making this an upstream packaging concern.