Commit graph

4 commits

Author SHA1 Message Date
Steve Ruiz
29044867dd
Add docs (#2470)
This PR adds the docs app back into the tldraw monorepo.

## Deploying

We'll want to update our deploy script to update the SOURCE_SHA to the
newest release sha... and then deploy the docs pulling api.json files
from that release. We _could_ update the docs on every push to main, but
we don't have to unless something has changed. Right now there's no
automated deployments from this repo.

## Side effects

To make this one work, I needed to update the lock file. This might be
ok (new year new lock file), and everything builds as expected, though
we may want to spend some time with our scripts to be sure that things
are all good.

I also updated our prettier installation, which decided to add trailing
commas to every generic type. Which is, I suppose, [correct
behavior](https://github.com/prettier/prettier-vscode/issues/955)? But
that caused diffs in every file, which is unfortunate.

### Change Type

- [x] `internal` — Any other changes that don't affect the published
package[^2]
2024-01-15 12:33:15 +00:00
Steve Ruiz
096df3209b
[1/2] Move docs to brivate (#1640)
This PR moves the docs site to the private repo while keeping the docs
content on the public repo.

### Change Type

- [x] `documentation`
2023-06-23 14:23:14 +00:00
Steve Ruiz
b9c6bf2fe8
Auto content refresh for docs site (#1606)
This PR improves the author experience when working on the docs site. 

When running `docs-dev`, the site's content will now update whenever a
content file is changed.

### Context

In the docs project, we generate content from two sources: from API
documentation generated by api-extractor and from markdown files in the
docs/content folder. Generating API docs is a relatively slow process
because it involves building and parsing TypeScript declaration files
for each package in the monorepo; however, generating docs from the
markdown files is basically instantaneous. The same script used to
address both tasks, which meant it was too slow to run on each save.
Instead, the script needed to be run manually or the dev server would
need to be restarted.

We now split the generation into two separate scripts. First, the script
runs to generate the API content; and then a second script runs to
generate the markdown content. The second script also imports and
combines the two sources of content. When we build the docs, both
scripts are run. When a markdown file changes, the new watcher only runs
the second script. This allows the site's content to be updated quickly
without having to generate the API docs each time.

Note that this does not incorporate live changes to package APIs, though
I can't think of a time where we be developing the docs and the APIs at
the same time.

### Change Type

- [x] `documentation` — Changes to the documentation only
2023-06-17 09:46:46 +00:00
alex
29ed921c67 transfer-out: transfer out 2023-04-25 12:01:25 +01:00