Documentation Plugins Architecture
The tupynambalucas.dev documentation workspace is strictly powered by Docusaurus v3 and uses a combination of standard React patterns and advanced Abstract Syntax Tree (AST) transformers.
1. Domain Plugin Wrappers (SSOT Architecture)
To enforce the Single Source of Truth (SSOT) and maintain a clean docusaurus.config.ts, the monorepo uses a Custom Docusaurus Preset (@tupynambalucas-dev/corporate-preset). This preset is the authoritative core that encapsulates and configures all underlying documentation engines.
Instead of declaring Docusaurus core plugins directly in the preset array, we use Domain Plugin Wrappers (located in corporate/packages/preset/src/plugins/):
content-docscontent-blogcontent-pages
The Wrapper Lifecycle
Each domain wrapper imports the native Docusaurus plugin (e.g., @docusaurus/plugin-content-docs), dynamically merges our enterprise rules, and then invokes the native plugin. This guarantees that every documentation instance—whether it is the primary handbook, the roadmap, or the workspaces specs—is forced to run through our sanitization and AST injection pipelines automatically.
- Option Validation: The wrappers re-export
validateOptionsto satisfy Docusaurus's strict schema validators. - AST Injection: The wrappers automatically append the custom
remark-project-variablesplugin to theremarkPluginsarray. - Context Preservation: The wrappers return the exact original name (e.g.,
docusaurus-plugin-content-docs) to ensure the React UI components correctly resolve the global context data during Server-Side Generation (SSG).
2. The remark-project-variables Plugin
To maintain a copy-pasteable, generic monorepo, the documentation MUST NOT contain hardcoded brand names or URLs (e.g., example.com). Instead, authors must write generic tokens using percentage wrappers, such as tupynambalucas.dev or Tupynambalucas.
How it Works
- AST Transformation: The custom
remark-project-variablesplugin hooks into the unified/remark MDX compilation pipeline. - Text Node Interception: It traverses the Markdown AST (
mdast) usingunist-util-visit. - Value Resolution: It intercepts nodes of type
text,inlineCode,link, andimage, and searches for patterns liketupynambalucas.dev. - Replacement: It replaces those tokens with actual values pulled from a single source of truth (
project.config.json) before the MDX is compiled into React JSX.
This architecture ensures that AI RAG embeddings (like the cortex/memory vectors) ingest the agnostic source files, avoiding brand hallucination when the repository is forked or applied to new clients.
3. Dynamic Collections and Localization (L10n)
To support multiple content instances and seamless GitOps-driven localization, the monorepo implements a dynamic Locales Sync Plugin (corporate/packages/preset/src/plugins/locales-sync/).
The Dynamic Lifecycle
Instead of manually checking in translated Docusaurus UI templates and hardcoding paths, the docusaurus.config.ts uses a custom collection property in the format [namespace]/[content] (e.g., portal/docs):
- Preset Orchestration: The Custom Preset intercepts the
docsandblogconfigurations, calculates the absolutepathfor the markdown files (collections/namespaces/[namespace]/content/[content]), and injects it dynamically into the engine. - Translation Extraction: Native Docusaurus
write-translationsdumps Chrome i18n JSON files (likecode.json,theme/navbar.json) which are stored securely incollections/namespaces/[namespace]/content/messages/. - Build-Time Unpacking: During the
pnpm portal:buildpipeline, theplugin-locales-syncdynamically reads the synchronizedlocales/[locale]/folders and maps them back into the native Docusaurus engine format insidei18n/[locale]/docusaurus-plugin-content-[type]-[id]/.
This plugin ensures complete separation between translated content and the executable Docusaurus engine, operating entirely on GitOps folder conventions without hardcoded mappings.