Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
98 changes: 71 additions & 27 deletions www/README.md
Original file line number Diff line number Diff line change
@@ -1,44 +1,88 @@
# Website
# Skip Documentation Website

The documentation website is built using [Docusaurus](https://docusaurus.io/).
This website is built using [Docusaurus](https://docusaurus.io/) and hosts both our documentation and blog.

## API Documentation

# API Documentation
The API documentation is generated using:
- [TypeDoc](https://typedoc.org/index.html) for API documentation generation
- [docusaurus-plugin-typedoc](https://typedoc-plugin-markdown.org/plugins/docusaurus) for Docusaurus integration

The API docs are generated by [TypeDoc](https://typedoc.org/index.html) and integrated into docusaurus using [docusaurus-plugin-typedoc](https://typedoc-plugin-markdown.org/plugins/docusaurus).
This setup needs the development/source docs site to be in the same repo as the sources, as there are relative paths in the docusaurus config file to the sources.
A separate deployment step will be needed to generate the docs and push them to the repo that feeds the live site.
This also means that we can iterate on the docs in the source repo without publishing them immediately, and then choose to publish them in sync with publishing packages.
### Development Setup

The workflow for working on API docs is:
```
- $ cd /path/to/repo/root
- $ make docs # to initialize the api docs
- $ make docs-run # to run the docs site locally
- visit http://localhost:3000/docs/api/core
- edit the doc comments in the sources
- $ make docs # to regenerate the api docs
The development/source docs site must be in the same repository as the source code due to relative paths in the Docusaurus configuration. This setup allows us to:
- Iterate on documentation in the source repository
- Choose when to publish documentation
- Keep documentation in sync with package releases

### Development Workflow

#### Standard Workflow
```bash
# From repository root INSIDE your Docker instance
make docs # Initialize API documentation

# From repository rood OUTSIDE your Docker instance
make docs-run # Run the docs site locally
# Visit http://localhost:3000/docs/api/core or http://localhost/blog

# After editing doc comments in the sources
make docs # Regenerate API documentation
```

A faster but not robust way to regenerate the api docs is:
```bash
cd /path/to/repo/root/www && npx docusaurus generate-typedoc
```
- cd /path/to/repo/root/www && npx docusaurus generate-typedoc
```
To publish the docs to the live site:
```
- $ make docs-publish

### Publishing Documentation

Before, commit your changes and send them for review
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Up to you, but I would suggest:

Suggested change
Before, commit your changes and send them for review
First commit your changes and send them for review

```bash
git add <your_files>
git commit -m '<some message>'
gh pr create # if you use the GitHub CLI
```
This will suggest to run:

When reviewed and merged, you are ready to publish documentation to the live site:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Up to you, but I would suggest:

Suggested change
When reviewed and merged, you are ready to publish documentation to the live site:
Once reviewed and merged, you are ready to publish documentation to the live site:

```bash
# From repository root INSIDE your Docker instance
make docs-publish
```

You should eventually read:
```bash
Test locally: make docs-serve
Push to live site: cd www/docs_site/; git add -A; git commit -m 'update to <commit>'; git push; cd -
```
Note that the docs_site commit messages will mention the wrong commit hashes if `make docs-publish` is run from a commit that is not (an ancestor of) `main`.

The documentation for the tags that TypeDoc recognizes is
[here](https://typedoc.org/guides/tags/).
The commit hash in the last line should be the hash of your commit in the skip repository.

> **Note**: If `make docs-publish` is run from a commit that is not (an ancestor of) `main`, the docs_site commit messages will contain incorrect commit hashes.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
> **Note**: If `make docs-publish` is run from a commit that is not (an ancestor of) `main`, the docs_site commit messages will contain incorrect commit hashes.
> **Note**: If `make docs-publish` is run from a commit that is not (an ancestor of) `main`, the docs_site commit messages will contain unreproducible commit hashes.

## Documentation Structure

- The markdown documentation under `www/docs` can be edited while the site is running at http://localhost:3000
- Changes to the `www/docs` file structure must be reflected in `www/sidebars.ts`
- The `docusaurus.config.ts` file is sensitive to the file system locations of source entry points and tsconfig files

Once the docs site is running at http://localhost:3000, the markdown documentation under `www/docs` can be edited and the changes are usually picked up automatically.
## TypeDoc Tags

Changes to the `www/docs` file structure usually need to be reflected in the `www/sidebars.ts` file.
You may refer to the [official documentation](https://typedoc.org/guides/tags/) of TypeDoc tags for more information.

The `docusaurus.config.ts` file is sensitive to the file system locations of the source entry points and tsconfig files.

## FAQ

### What if my `docs_site` is not on the `main` branch ?
Clean up your repository is good idea at this point and then start the process again:
```bash
git pull --rebase # ensure that your local docs_site submodule is up-to-date
git clean -Xdn # -n for a dry-run and double-check what's to be cleaned out
git clean -Xdf # the actual cleaning
```

### What if the hash in the suggested commit message is not the hash of your commit?
You can get it from the skip repository:
```bash
git rev-parse --short HEAD # supposingly it is the last commit of the branch
```
Comment on lines +76 to +88
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't mean to be difficult, but I still don't understand. I'm not sure if two potential issues are being mixed up. The two issues I am aware of are:

  1. The local docs_site submodule is behind the upstream one.
  2. There is one or more local commits that have not been merged into the upstream main branch.

For 1., the symptom is that the git push suggested by make docs-publish complains about needing --force. In this situation, we do not want to force push, but should instead update the docs_site submodule and regenerate the docs and try to publish again.

For 2., the symptom is that git merge-base HEAD origin/main is not equal to HEAD, which will lead to the commit message suggested by make docs-publish to contain a <commit> that is only local. In this situation we do not want to change that commit message, we want to make sure that the HEAD commit that we publish is an ancestor of origin/main.

So there are potential confusions in these FAQs:

  1. The solution for docs_site being out of date is to update the submodule. The cleaning is independent of docs, and is just a general issue due to missing dependencies in the build system that are sometimes encountered when updating across a bootstrap of the skiplang compiler or runtime system.
  2. The FAQ is not clear. The hash in the suggested commit message is correct, it just might be that the commit is not merged into origin/main. The FAQ makes it sound like the commit message should be changed, but that is not the right action.