remove old hugo content

update readme
reference docusaurus
remove hugo content and theme

Author: raphael-istari

README.md

@@ -1,222 +1,153 @@
 # Dgraph Documentation
 
 To read the official Dgraph documentation that is published from this repository,
-please see https://dgraph.io/docs/.
+please see https://docs.dgraph.io/.
 
+## Technology Stack
 
+This documentation site is built with [Docusaurus](https://docusaurus.io/), a modern static website generator optimized for documentation.
 
-## Contribution guidelines
+## Documentation Structure
 
-As a contributor to Dgraph documentation, we ask that you do the following:
-- **Label your PR for easy management**: Your PR title should be in the following format: **Topic (area): details**. The **topic** is either "Docs", "Nav" (aka, navigation), or "Chore" (for build fixes, cherry-picks, etc). The **area** is the feature (i.e. "GraphQL"), area of the docs (i.e., "Deployment"), or "Other" (for typo fixes and other bugfix PRs). So, example PR names include:
- *Docs(GraphQL): Document the @deprecated annotation* or *Chore(Other): cherry-pick updates from main to release/v20.11*
-- **Develop in the `main` branch first**: Make any changes applicable to the current (recently-released) version of Dgraph in the `main` branch first, and then cherry-pick those changes to the correct release branch (for example, `release/v20.11`).
-
- **Exception**: Changes that *only* apply to older Dgraph versions (for example `release/v20.07`), can occur directly in a release branch, but will not be cherry-picked forward.
-- **Note planned cherry-pick(s) in your PR description**: If you are creating a PR in `main` and you know it needs to be cherry-picked to a release branch, please mention that in your PR description (for example: "cherry-pick to v20.07"). Cherry-pick PRs should reference the original PR.
-
-- **Link to discuss.dgraph.io posts when applicable**: If your PR is based on discussions on Discuss, feel free to include a link to the relevant discussion in your PR description.
-
-- **Technical writing style**: As much as possible, please follow technical writing style conventions (More on this below).
-
-- **(Dgraph core team only)**: Include the ID of any issues/tickets related to your PR in the description (i.e., "Fixes DGRAPH-12345" or "Per DGRAPH-54321").
-
-### Technical writing style
+The documentation is organized into four main sections, each managed by its own Docusaurus content plugin:
 
-Dgraph Labs uses a style guide for our documentation so that we can make it as easy to understand as possible. The [Dgraph Style Guide](https://discuss.dgraph.io/t/dgraph-developer-documentation-style-guide/10955) is a concise style reference for our documentation, but it isn't comprehensive. For anything not found in our style guide, use Google's [Developer Docs Style Guide](https://developers.google.com/style/highlights).
+1. **Docs** (`/`) - Core Dgraph database documentation including DQL, administration, installation, and design concepts
+2. **GraphQL** (`/graphql`) - GraphQL API documentation, schema, queries, mutations, and custom resolvers
+3. **Ratel UI** (`/ratel`) - Documentation for the Ratel web-based UI tool
+4. **Tutorials** (`/learn`) - Step-by-step tutorials and learning paths for different user types
 
-#### Style tips for machine-translatable docs!
+Each section has its own sidebar navigation configured in:
+- `sidebars.ts` - Docs sidebar
+- `sidebars-graphql.ts` - GraphQL sidebar
+- `sidebars-ratel.ts` - Ratel sidebar
+- `sidebars-learn.ts` - Tutorials sidebar
 
-Making our documentation easy to understand includes optimizing it for client-side machine translation into other languages. To help with this, please see the following technical writing style tips:
-- Generally, use the second person ("you") rather than the third-person ("the developer") when addressing the reader.
-- Always use the third person when describing Dgraph database or features (avoid "this lets us" in favor of "this lets Dgraph").
-- Write in present-tense, active voice when you can.
-- Prefer simple sentences to complex and complex-compound sentences.
+## Running Locally
 
-**Note:** Please don't let these style conventions stop you from creating a PR to share your contribution to Dgraph Docs! PR reviewers can help with style guide issues.
+### Prerequisites
 
-### references ###
+- [Node.js](https://nodejs.org/) version 20.0 or higher
+- npm or yarn package manager
 
-Use hugo shortcode for relref.
+### Setup and Run
 
-Example, to reference a term, use a relref to the glossary :
-```
->  [entity]({{< relref "dgraph-glossary.md#entity" >}})
-```
+1. Navigate to the Docusaurus directory:
+   ```bash
+   cd docusaurus-docs
+   ```
 
-### Staging doc updates locally
+2. Install dependencies:
+   ```bash
+   npm install
+   ```
 
-We use [Hugo](https://gohugo.io/) for our documentation. You can use Hugo to locally stage doc updates before or after creating a PR.
+3. Start the development server:
+   ```bash
+   npm start
+   ```
 
-1. Download and install  hugo version v0.91 from [here](https://github.com/gohugoio/hugo/releases/tag/v0.91.0).
+4. Open [http://localhost:3000](http://localhost:3000) in your browser.
 
-On mac you may have to remove the quarantine attribute to be able to execute hugo
-'''
-sudo xattr -d com.apple.quarantine path/to/hugo
-'''
+The site will automatically reload when you make changes to the documentation files.
 
-2. Run `./scripts/local.sh` and visit [http://localhost:1313](http://localhost:1313) to see the documentation site running on your local machine.
+### Build for Production
 
-(Optional) To run queries _within_ the documentation using a different Dgraph instance, set the `DGRAPH_ENDPOINT` environment variable before starting the local web server:
+To build a production-ready static site:
 
 ```bash
-DGRAPH_ENDPOINT="http://localhost:8080/query?latency=true" ./scripts/local.sh
+npm run build
 ```
 
-Now you can make changes to the docs and see them being updated instantly, thanks to Hugo.
+The built site will be in the `build/` directory. You can serve it locally with:
 
-**Note**: While running locally, the version selector does not work because you need to build the documentation and serve it behind a reverse proxy to have multiple versions. Also, formatting of lists is less fussy when running locally; so please precede lists with a blank line in your PR.
+```bash
+npm run serve
+```
 
-### Testing for broken links
+## Versioning
 
-We use [htmltest](https://github.com/wjdp/htmltest) to check for broken links in the generated documentation. To test for broken links after building the site:
+Docusaurus supports documentation versioning. Versioned documentation is stored in:
+- `docs_versioned_docs/` - Versioned docs content
+- `docs_versioned_sidebars/` - Versioned sidebar configurations
+- `docs_versions.json` - Version metadata
 
-1. Build the Hugo site:
-   ```bash
-   hugo --destination=public --baseURL=http://example.com
-   ```
+The version dropdown in the navbar automatically detects which documentation section you're viewing and shows the appropriate versions. Currently, versioning is configured for the main `docs` section.
 
-2. Run htmltest:
-   ```bash
-   htmltest
-   ```
+To create a new version:
+1. Use the Docusaurus CLI: `npm run docusaurus docs:version <version>`
+2. This creates a new version snapshot of the current docs
 
-   Or combine both steps:
-   ```bash
-   hugo --destination=public --baseURL=http://example.com && htmltest  2>&1
-   ```
+## Deployment
 
-The htmltest configuration is in `.htmltest.yml` at the root of the repository. It automatically ignores development-only files like `livereload.js` and empty hash links used for JavaScript interactions.
+The documentation site is automatically deployed to CloudFlare:
 
-### Running docs locally with Docker
+- **Main branch** (`main`) → Deployed to production at `https://docs.dgraph.io`
+- **Preview branches** (`preview/*`) → Deployed as preview deployments for review
 
-Make sure you have docker-compose installed.
+The deployment process is handled automatically via CloudFlare Pages integration with GitHub.
 
-Run:
+## Contribution Guidelines
 
-```sh
-sh scripts/docker.sh
-```
-
-### Branch
-
-Depending on what branch you are on, some code examples will dynamically change.
-For example, `go-grpc` code examples will have different import path depending
-on the branch name.
+As a contributor to Dgraph documentation, we ask that you do the following:
+- **Label your PR for easy management**: Your PR title should be in the following format: **Topic (area): details**. The **topic** is either "Docs", "Nav" (aka, navigation), or "Chore" (for build fixes, cherry-picks, etc). The **area** is the feature (i.e. "GraphQL"), area of the docs (i.e., "Deployment"), or "Other" (for typo fixes and other bugfix PRs). So, example PR names include:
+ *Docs(GraphQL): Document the @deprecated annotation* or *Chore(Other): cherry-pick updates from main to release/v20.11*
+- **Develop in the `main` branch first**: Make any changes applicable to the current (recently-released) version of Dgraph in the `main` branch first, and then cherry-pick those changes to the correct release branch (for example, `release/v20.11`).
 
-## Runnable code examples
+ **Exception**: Changes that *only* apply to older Dgraph versions (for example `release/v20.07`), can occur directly in a release branch, but will not be cherry-picked forward.
+- **Note planned cherry-pick(s) in your PR description**: If you are creating a PR in `main` and you know it needs to be cherry-picked to a release branch, please mention that in your PR description (for example: "cherry-pick to v20.07"). Cherry-pick PRs should reference the original PR.
 
-Some code examples are runnable, allowing for reader interaction with a data set.
+- **Link to discuss.dgraph.io posts when applicable**: If your PR is based on discussions on Discuss, feel free to include a link to the relevant discussion in your PR description.
 
-### Custom example
+- **Technical writing style**: As much as possible, please follow technical writing style conventions (More on this below).
 
-Pass custom Go-GRPC example to the runnable by passing a `customExampleGoGRPC` to the `runnable` shortcode.
+- **(Dgraph core team only)**: Include the ID of any issues/tickets related to your PR in the description (i.e., "Fixes DGRAPH-12345" or "Per DGRAPH-54321").
 
-```
-{{< runnable
-  customExampleGoGRPC="this\nis\nan example"
->}}{
-  director(func:allofterms(name, "steven spielberg")) {
-    name@en
-    director.film (orderdesc: initial_release_date) {
-      name@en
-      initial_release_date
-    }
-  }
-}
-{{< /runnable >}}
-```
+### Technical Writing Style
 
-**Note:** Runnable doesn't support passing a multiline string as an argument to a shortcode. Therefore, you have to create the whole custom example in a single line string by replacing newlines with `\n`.
+Please follow the [Dgraph Documentation Style Guide](documentation-style-guide.md) for writing conventions, formatting, and best practices.
 
-## Hints
-## Adding New Tabs and Sidebar Menus
+**Note:** Please don't let these style conventions stop you from creating a PR to share your contribution to Dgraph Docs! PR reviewers can help with style guide issues.
 
-To add a new tab and configure its sidebar menu:
+### References
 
-### 1. Add Tab to Navigation
-Edit `themes/hugo-docs/layouts/partials/topbar.html` and add your tab to the `$tabs` slice:
+In Docusaurus, use standard Markdown links for internal references. For example, to reference a term in the glossary:
 
-```go
-{{ $tabs := slice 
-  (dict "type" "docs" "url" "/dgraph-overview/" "label" "Docs")
-  (dict "type" "graphql" "url" "/graphql/" "label" "GraphQL") 
-  (dict "type" "learn" "url" "/learn/" "label" "Tutorials")
-  (dict "type" "ratel" "url" "/ratel/overview/" "label" "Ratel UI")
-  (dict "type" "yourtype" "url" "/your-section/" "label" "Your Tab")
-}}
-```
 
-### 2. Set Page Type and Menu
-For each page in your section, add to the frontmatter:
-
-```yaml
-+++
-title = "Your Page Title"
-type = "yourtype"  # Must match the type in the tab definition
-[menu.yourtype]   # Must match the type
-  parent = "your-section"
-  weight = 1
-+++
+```markdown
+[UID](/dgraph-glossary#uid)
 ```
 
-### 3. Update Sidebar
-Edit `themes/hugo-docs/layouts/partials/sidebar.html` and add:
+## File Structure
 
-```go
-{{ if eq $menuType "yourtype" }}
-  {{ $menu = .Site.Menus.yourtype }}
-{{ end }}
 ```
-
-## Multi-Version Documentation
-
-This repository uses a build script to generate documentation for multiple versions from different Git branches.
-
-
-```bash
-./scripts/build.sh
+docusaurus-docs/
+├── docs/              # Main documentation content
+├── docs-graphql/      # GraphQL documentation
+├── docs-ratel/        # Ratel UI documentation
+├── docs-learn/        # Tutorials and learning content
+├── docs_versioned_docs/    # Versioned documentation snapshots
+├── sidebars.ts        # Main docs sidebar configuration
+├── sidebars-graphql.ts     # GraphQL sidebar configuration
+├── sidebars-ratel.ts       # Ratel sidebar configuration
+├── sidebars-learn.ts       # Tutorials sidebar configuration
+├── docusaurus.config.ts    # Main Docusaurus configuration
+└── src/               # Custom components and styles
 ```
 
-This builds:
-- **Latest docs** from `main` branch → `/`
-- **Version docs** from release branches → `/v24.1/`, etc.
-
-## How It Works
+## Testing
 
-1. **Build Script** (`build.sh`) uses Git worktrees to temporarily check out each release branch
-2. **Hugo builds** each version into its own subdirectory with the appropriate base URL
-3. **Version selector** loads available versions from `versions.json` and displays a dropdown
+### Type Checking
 
-## Configuration
+Run TypeScript type checking:
 
-Edit `build.sh` to add/remove versions:
 ```bash
-VERSION_BRANCHES=("main" "release/v24.1")
+npm run typecheck
 ```
 
-```bash
-VERSION_BRANCHES=("release/v25.0" "release/v24.1")
-```
-
-## File Structure
-
-```
-layouts/partials/
-  └── version-selector.html    # Dropdown component
-scripts/
-  └── build.sh         # Build script
-public/                         # Generated output
-  ├── index.html               # Latest docs (main)
-  ├── versions.json            # Version metadata
-  ├── v24.1/                   # Version 24.1 docs
-  └── v24.2/                   # Version 24.2 docs
-```
+### Link Checking
 
-### Version Selector
+After building the site, you can check for broken links using external tools or by manually testing the built site.
 
-In  layout 
+## Runnable Code Examples
 
-```html
-{{ partial "version-selector.html" . }}
-```
+Some code examples in the documentation are interactive and runnable, allowing readers to execute queries directly in the browser. These are implemented using custom Docusaurus components.