Files
nrwl--nx/astro-docs/README.md
T
2026-07-13 12:38:36 +08:00

369 lines
13 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Nx Documentation Site
[![Built with Starlight](https://astro.badg.es/v2/built-with-starlight/tiny.svg)](https://starlight.astro.build)
The Nx documentation site built with Astro and Starlight, featuring advanced content management through Markdoc and dynamic plugin documentation generation.
## Architecture Overview
This documentation site leverages Astro's static site generation capabilities with Starlight for documentation-specific features. The architecture consists of:
### Core Technologies
- [**Astro**](https://docs.astro.build) - Static site generator with island architecture
- [**Starlight**](https://starlight.astro.build) - Documentation theme with built-in navigation, search, and i18n
- **React** - For implementing UI components
- **Netlify** - Deployment and hosting
### Key Features
- [Markdoc](https://markdoc.dev) with custom tags for rich content such as videos, graphs, etc.
- TailwindCSS for styling in Astro and React components
- Dynamic API documentation generation from Nx packages and CLI commands
- Community plugin registry
## Information Architecture Principles
When creating or reorganizing documentation, follow these 5 principles to determine where content belongs.
### 1. Progressive Disclosure (The "Journey" Rule)
- **Concept:** Don't overwhelm the user. Reveal complexity only as they advance in their journey.
- **The Test:** _Is this for the First 30 Minutes (Getting Started), the First 30 Days (Features), or Forever (Reference)?_
### 2. Category Homogeneity (The "Scan" Rule)
- **Concept:** Items in a list must be of the same "type" (noun, verb, or concept) to reduce cognitive load.
- **The Test:** _Does this list mix Concepts (Mental Model), Tasks (Update Nx), and Products (React)? If yes, split it._
### 3. Type-Based Navigation (The "Intent" Rule)
- **Concept:** Separate **Learning** (Narrative/Guides) from **Looking Up** (Reference/API).
- **The Test:** _Is the user here to learn a workflow (Guide) or look up a flag syntax (Reference)?_
### 4. The Pen & Paper Test (The "Theory" Rule)
- **Concept:** Distinguish Architecture from Features to keep "Core Concepts" pure.
- **The Test:** _Can I explain this using only a pen and paper?_
- **Yes:** It goes in **How Nx Works** (Architecture).
- **No (I need a terminal):** It goes in **Platform Features** (Feature).
### 5. Universal vs. Specific (The "Placement" Rule)
- **Concept:** Distinguish Platform features from Ecosystem tools to prevent "Features" from becoming a junk drawer.
- **The Test:** _Does this feature apply to EVERY user (e.g., Caching, Agents)?_
- **Yes:** **Platform Features**.
- **No (Only React users):** **Technologies**.
### Sidebar Structure
The sidebar has 4 top-level sections that follow the user journey:
1. **Getting Started** - Essential setup, tutorials, and core concepts (How Nx Works, Platform Features)
2. **Technologies** - Framework and tool-specific guides (React, Angular, Node, build tools, test tools)
3. **Knowledge Base** - Recipes, troubleshooting, and topic-specific guides
4. **Reference** - Exhaustive facts, no narrative (CLI commands, configuration, API docs)
## Project Structure
```
astro-docs/
├── src/
│ ├── assets/ # Images and static assets to be optimized by Astro
│ │ ├── nx/ # Nx branding assets
│ │ ├── nx-cloud/ # Nx Cloud assets
│ │ └── nx-console/ # Nx Console assets
│ ├── components/ # React and Astro components
│ │ ├── layout/ # Layout components (e.g. Sidebar)
│ │ ├── markdoc/ # Markdoc tag components
│ │ └── utils/ # Utility functions
│ ├── content/ # Documentation content
│ │ ├── banner.json # Banner collection (generated by prebuild-banner)
│ │ ├── docs/ # Main documentation files (.mdoc, .mdx)
│ │ └── approved-community-plugins.json # Powers plugin registry
│ ├── pages/ # Dynamic pages and routes (e.g. devkit)
│ ├── plugins/ # Content loaders and plugins
│ │ ├── *.loader.ts # Dynamic content loaders (e.g. CLI commands and API docs generation)
│ │ └── utils/ # Plugin utilities
│ └── styles/ # Global styles
├── public/ # Static assets not to be optimized by Astro (fonts, robots.txt)
├── astro.config.mjs # Astro configuration
├── markdoc.config.mjs # Markdoc tags configuration
├── sidebar.mts # Sidebar structure definition
└── package.json
```
## Plugins and Loaders
### Content Loaders
The site uses custom content loaders to dynamically generate documentation:
- **PluginLoader** (`plugin.loader.ts`) - Generates official plugin documentation (generators, executors, migrations)
- **CommunityPluginsLoader** (`community-plugins.loader.ts`) - Generates data for plugin registry (e.g. GitHub stars, npm downloads)
- **NxReferencePackagesLoader** (`nx-reference-packages.loader.ts`) - Generated data for CNW, Devkit, nx cli (e.g. nx core related things)
## Content Management
### Content Types
1. **Regular Documentation** (`src/content/docs/`)
- Written in `.mdoc` (Markdoc) or `.mdx` (MDX) format
- Organized by sections: getting-started, concepts, guides, api
- File-based routing (filename = URL path)
2. **Dynamic Plugin Documentation**
- Auto-generated from Nx packages
- Includes generators, executors, and migrations
- Updated during build process
- **Note**: Requires a rebuild and restart to reflect changes
3. **CLI Documentation**
- Auto-generated from Nx CLI commands
- Parsed from actual CLI implementation
- **Note**: Requires a rebuild and restart to reflect changes
### Markdoc Tags
The site includes custom Markdoc tags for rich content.
**Note**: Starlight supports many Markdown and Markdoc features, such as code blocks, asides, etc.
- https://starlight.astro.build/components/using-components/#using-a-component-in-markdoc
- https://starlight.astro.build/guides/authoring-content
#### Layout & Organization
- `{% aside %}` - Highlighted information boxes
- `{% cardgrid %}`, `{% card|linkcard %}` - Card layouts
- `{% tabs %}`, `{% tabitem label="some-label" %}` - Tab layouts
- Use the `syncKey` so tabs are auto switched to the users preference if it makes sense.
- e.g. `{% tabs syncKey="package-manager" %}`
#### Interactive Components
- `{% graph %}` - Interactive project/task graph visualization
- `{% project_details %}` - Project configuration viewer
#### Media & Embeds
- `{% youtube %}` - YouTube video embeds
- `{% video_player %}` - Custom video player
- `{% iframe %}` - Generic iframe embeds
#### Developer Tools
- `{% github_repository %}` - GitHub repo cards
- `{% stackblitz_button %}` - StackBlitz demo launcher
- `{% install_nx_console %}` - IDE extension installer
#### Content Enhancement
- `{% badge %}` - Status/label pills
- `{% metrics %}` - Metrics display
- `{% testimonial %}` - Customer testimonials
## Development Workflow
### Getting Started
```bash
# Install dependencies and link workspace packages
# This will build Nx packages as well for API docs
nx serve astro-docs
# Or run astro dev directly
# This will not build Nx packages
cd astro-docs
npx astro dev
# Custom ports (useful for AI agents with git worktrees)
npx astro dev --port 3000
```
### Adding New Content
#### Regular Documentation
1. Create `.mdoc` file in `src/content/docs/`
2. Add frontmatter with title and description
3. Use Markdoc tags for rich content
4. File location determines URL structure
Example:
```markdown
---
title: 'My New Guide'
description: 'Learn how to use this feature'
---
# Introduction
{% aside type="note" title="Important" %}
This is a note about the feature.
{% /aside %}
```
#### Adding Custom Markdoc Tags
1. Create Astro component in `src/components/markdoc/`
2. (Optional) Create React component for more complex components, or ones that need to be shared with blog or non-docs pages
3. Register in `markdoc.config.mjs`
4. Define attributes and validation
### Updating Plugin Documentation
Plugin documentation is auto-generated during build. To update:
1. Make changes to the plugin's schema/implementation
2. Run the build process
3. The loader will automatically fetch and generate updated docs
### Sidebar Management
The sidebar structure is defined in `sidebar.mts`. To add new sections:
```javascript
export const sidebar = [
{
label: 'Section Name',
items: [
{
label: 'Page Title',
link: 'path/to/page',
},
// Nested sections
{
label: 'Subsection',
collapsed: true,
items: [...]
}
]
}
];
```
> Note there is a special case for sidebar items appearing in the sidebar. Such as the `Reference` section which is handled via the `[sidebar-reference-updater](./src/plugins/sidebar-reference-updater.middleware.ts)` middleware.
## Styling and Theming
- Uses Tailwind CSS v4 with Vite plugin
- Global styles in `src/styles/global.css`
- Component-specific styles use Tailwind utilities
- Dark/light mode support built into Starlight and customized in `global.css`
## Configuration Files
### `astro.config.mjs`
- Site configuration
- Integration setup (React, Markdoc, Starlight)
- Vite plugins
- Build options
### `markdoc.config.mjs`
- Custom tag definitions
- Attribute validation
- Component mappings
### `sidebar.mts`
- Navigation structure
- Section organization
- Dynamic content injection points
## Banner Configuration
The floating banner promotes events/webinars. It's fetched at **build time** from a Framer CMS page and stored as an Astro content collection.
### Setup
Set `BANNER_URL` to point to a Framer page that renders banner JSON:
```
BANNER_URL=https://your-framer-site.framer.app/api/banners/main
```
The Framer page should render JSON inside a `<pre>` tag:
```json
{
"title": "Event Title",
"description": "Event description",
"primaryCtaUrl": "https://...",
"primaryCtaText": "Learn More",
"secondaryCtaUrl": "",
"secondaryCtaText": "",
"enabled": true,
"activeUntil": "2025-12-31T00:00:00.000Z"
}
```
### Schema
| Field | Type | Required | Description |
| ------------------ | -------- | -------- | ------------------------- |
| `title` | string | Yes | Banner headline |
| `description` | string | Yes | Banner body text |
| `primaryCtaUrl` | string | Yes | Primary button URL |
| `primaryCtaText` | string | Yes | Primary button text |
| `secondaryCtaUrl` | string | No | Secondary button URL |
| `secondaryCtaText` | string | No | Secondary button text |
| `enabled` | boolean | Yes | Show/hide the banner |
| `activeUntil` | ISO 8601 | No | Auto-hide after this date |
### Behavior
- Banner is fetched during `prebuild-banner` target and saved to `src/content/banner.json` as a collection (array)
- Uses Astro content collection with `file()` loader and schema validation
- Requires rebuild/redeploy to update the banner
- Users can dismiss the banner (stored in localStorage)
- If `enabled` is `false` or `activeUntil` has passed, the banner won't show
- If `BANNER_URL` is not set, an empty collection is generated
## Versioned Docs
When a new major Nx version is released (or about to be released), create a versioned snapshot of the docs site so the previous version remains accessible at `{major}.nx.dev` (e.g. `22.nx.dev`).
### Creating a Version Snapshot
```bash
node ./scripts/create-versioned-docs.mts 22
```
This will:
1. Fetch tags from origin, find the latest stable release for that major (e.g. `22.6.4`)
2. Checkout that tag, install deps, and build the docs site
3. Create an orphan git branch `22` containing only the pre-built static site plus minimal scaffolding (root `package.json`, `nx.json`, `pnpm-lock.yaml`, `netlify.toml`, and a no-op `nx-dev` project) so Netlify's configured build command succeeds instantly
4. Return to your original branch
If no stable tags exist for that major version, it builds from the current branch.
For Nx 21+, the script builds `astro-docs` (Astro/Starlight). For legacy Nx 1820, it builds `nx-dev` (Next.js with static export) — this path will be removed once those versions are no longer maintained.
#### Flags
- `--force` — overwrite an existing local/remote `{major}` branch
- `--redirect-to-prod` — skip the build and produce a branch that 301s every path to `https://nx.dev/docs`. Used to retire an old versioned subdomain (e.g. `16.nx.dev`) without maintaining its docs
```bash
# Retire an old versioned site
node ./scripts/create-versioned-docs.mts 16 --redirect-to-prod
```
### Pushing the Branch
```bash
git push -f origin 22
```
### Deployment Setup
Versioned sites are served via Netlify branch deploys of the main `nx-dev` Netlify site, with custom domains managed in Squarespace.
- **Netlify** — each `{major}` branch is deployed as a [branch deploy](https://docs.netlify.com/site-deploys/overview/#branch-deploy-controls) of the `nx-dev` site. The branch's root `netlify.toml` overrides the UI build settings so Netlify serves the pre-built static files (no rebuild, no `@netlify/plugin-nextjs`). Add the branch to the site's branch deploy allowlist, then add `{major}.nx.dev` as a domain alias pointing at the branch deploy
- **Squarespace** — DNS for `nx.dev` is managed in Squarespace. Add a CNAME for `{major}` pointing at the Netlify branch deploy hostname