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]
This PR adds a bare-minimum note to the Translations page on the docs
site.
### Change Type
- [x] `documentation` — Changes to the documentation only[^2]
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. Take a look at the Translations docs page.
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- [docs] Added brief info on how to join as a translations contributor.
---------
Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
This PR adds a contributor license agreement (CLA) to the project.
Contributors will need to sign the CLA before we merge their PRs. This
will be handled automatically via a bot here on GitHub.
## Context
Did you know tldraw is a [venture
backed](https://tldraw.substack.com/p/tiny-little-seed-round) company?
Our CLA is designed to protect our options for any future re-licensing
of the project's code or transferring ownership, which can become
complicated when taking public contributions community, but which can
become necessary by fate and/or go to market strategies.
A CLA adds a bit of friction and hassle for contributors, however I'd
prefer to be upfront about our relationship rather than doing what many
open source projects have done in the past, which is relicensing code
contributed without such prior agreement.
If you have any questions, feel free to post them below.
### Change Type
- [x] `internal` — Any other changes that don't affect the published
package (will not publish a new version)