Describe what your pull request does. If appropriate, add GIFs or images
showing the before and after.
### Change Type
- [ ] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [x] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [ ] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. Add a step-by-step description of how to test your PR here.
2.
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- Fix typo in useValue comment.
Adds an example of how to add migrations for a custom shape.
closes tld-2246
- [x] `documentation` — Changes to the documentation only[^2]
### Release Notes
- Adds a shape with migrations example
---------
Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
This PR adds tooling to enable a PR-based workflow for publishing
'patch' releases.
### How releases currently work
Quick recap of how the 'major' and 'minor' releases work:
- You trigger them manually in the github actions UI
- It only works on the `main` branch.
- You select a mode: `'major'`, `'minor'`, or `'override'` with a
specific version. The override option is mainly for transitioning in and
out of prerelease mode, but potentially also skipping unlucky numbers
like 13 if you're feeling superstitious 🧙🏼
- It bumps the version numbers in the `package.json` and `version.ts`
files.
- It compiles a changelog based on descriptions/titles from all the PRs
that have gone in to `main`.
- It tags the commit with the version number e.g. `v2.0.0` and pushes
all the changes made to `main` (i.e. changelogs, version bumps and the
tag)
- It creates a github release, e.g.
https://github.com/tldraw/tldraw/releases/tag/v2.0.0
- It deploys the packages to npm
- It tells huppy bot about the release (for now-defunct purposes, we can
remove that code later)
- It triggers the template repo update workflow
### Introducing: Release Branches
This PR adds one step into the above process: creating a 'release'
branch. e.g. if it publishes a new version tagged `v2.1.0` it will also
create a branch named `v2.1.x`.
These branches are protected in the following ways:
- Only huppy bot can create or delete them (ad-hoc admin overrides are,
of course, still doable should the need arise)
- Like `main` they can only be updated via pull request.
The process to create a patch release becomes simple:
1. Checkout the `v<major>.<minor>.x` branch you want to create a patch
release for. e.g.
git fetch && git checkout v2.1.x
4. Branch off, e.g.
git checkout -b david/my-patch-release
6. Cherry-pick any commits you need from `main` into your branch,
resolving any conflicts if they arise. **important**: don't do new work
here because it won't be merged back into `main` automatically. Fix the
thing in `main` first and then cherry-pick, unless you're in a big rush
or whatever. e.g.
git cherry-pick abdeaf234 cde234d09 ab23af287
7. Push your new branch to github as normal and make a PR targeting the
`v<major>.<minor>.x` branch.
8. Merge it.
Congratulations, you just triggered a patch release build.
### What happens (differently) during a patch release build.
⚡ A key thing to understand here is that **this script allows us to
deploy patch versions of _older_ major/minor releases**. This will
happen when we have customers pinned to older versions and they need a
quick bugfix but don't have time to upgrade to the latest due to some
breaking change. This will also happen if we ever adopt a kind of 'LTS'
release model.
With that said, here's how things go down differently:
- Firstly, the build happens automatically after the PR is merged, and
you don't select 'major' or 'minor' or anything, it just does its thing.
- It bumps the version numbers in the `package.json` files and the
`version.ts` files but these changes stay within the release branch,
they don't get propagated to `main` (nor should they).
- It compiles a changelog entry featuring just your one PR's
description/title, and also pushes this to the release branch (but not
`main`).
- It still tags the commit and creates a github release as normal.
- It still deploys the packages to npm (obvs). HOWEVER it only uses the
`latest` tag if this will indeed be the latest version of the public
packages. Otherwise, if we're patching an older release, it uses the
`revision` tag. Unfortunately it doesn't seem to be an option to deploy
with _no_ tag, but using `revision` still allows version strings like
`~2.0.0` to capture subsequent patch releases like `2.0.3`.
- Similarly it _only_ notifies huppy bot and _only_ triggers the
template repo update if the version being deployed is actually the
latest version.
I'm going to merge this now to test it out but I'd still appreciate
reviews.
Adds tests for the Vec.Average. [My previous
PR](https://github.com/tldraw/tldraw/pull/3065) added a check that
prevented returning vectors with NaNs, this adds a test for that.
### Change Type
- [ ] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [x] `tests` — Changes to any test code only[^2]
- [ ] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
Describe what your pull request does. If appropriate, add GIFs or images
showing the before and after.
### Change Type
- [ ] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [x] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [ ] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
Look at the revised documentation
### Release Notes
N/A
Two examples:
One in the UI section that shows how to add a tool to the toolbar along
with an icon
One in the shapes and tools section that shows a simple sticker tool
with no child states
I'll go over the copy again before it's merged, but don't want to spend
too long on it right now in case the feeling is that these should both
be a single example.
Next: The [minimal
example](https://tldraw.dev/examples/editor-api/only-editor) is
currently the best example we have of a tool with child states. I think
this should be adapted and copied/moved over to the custom shapes and
tools category.
closes tld-2266
- [x] `documentation` — Changes to the documentation only[^2]
### Release Notes
- Adds a simple custom tool example
Should fix `At instance.duplicateProps.offset.x: Expected a number, got
NaN` validation errors.
Wasn't able to reproduce. We only assign the offset here, so
`Vec.Averge` is the most likely offender here and for that to happen I
guess `movingShapes` might not contain any shapes.
### Change Type
- [x] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [ ] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. Add a step-by-step description of how to test your PR here.
2.
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- Add a brief release note for your PR here.
This is a generated file that shouldn't be checked in.
### Change Type
- [x] `internal` — Any other changes that don't affect the published
package[^2]
Right now it's fairly easy to encounter a situation when a tab coming
online wouldn't recognise that the connection can now be reestablished
for a while. This PR cleans up reconnection logic, reenables tests, and
makes sure we get online as robustly as possible.
### Change Type
- [x] `patch` — Bug fix
### Test Plan
1. Check that reconnection works as expected
- [x] End to end tests
---------
Co-authored-by: David Sheldrick <d.j.sheldrick@gmail.com>
This PR shortens the URL parameters for the dot com. Old formal still
works but this is shorter (it has bugged me for ages).
Before:
tldraw.com/r/ok?viewport=0,0,1080,720&page=page:ashdsad_sadsadasd
After:
tldraw.com/r/ok?v=0,0,1080,720&p=ashdsad_sadsadasd
### Change Type
- [x] `internal`
### Test Plan
1. Try the old url parameter format.
2. Try the new one.
### Release Notes
- Shortens url parameters for dot com.
Fixed an issue where the video size was drawing larger than the shape
size.
After:
Before:
### Change Type
- [x] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [ ] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
no tests
### Release Notes
- Fix an issue where the video size was not drawn correctly.
Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
Steve tried this in #3043, but we reverted it in #3063. Steve's version
added `JSON.parse`/`JSON.stringify` to the helpers without checking for
where we were already `JSON.parse`ing (or not). In some places we just
store strings directly rather than wanting them jsonified, so in this
version we leave the jsonification to the callers - the helpers just do
the reading/writing and return the string values.
### Change Type
- [x] `patch` — Bug fix
We use `children: any` in a bunch of places, but the proper type for
these is `ReactNode`. This diff fixes those.
### Change Type
- [x] `patch` — Bug fix
This PR fixes the input tags, which were set to `false` rather than
`off`, as they should be.
### Change Type
- [x] `patch` — Bug fix
### Test Plan
1. Test autocomplete
2. Test autocapitalize
3. Test autocorrect
4. Make sure that password managers don't show up
### Release Notes
- Fixed autocomplete, autocapitalize, and autocorrect tags on text
inputs.
This PR lets firefox users scroll the keyboard shortcuts dialog
**horizontally**.
This isn't a real solution, just a plea for help for any ideas on how to
fix this in a better way.
Firefox users haven't been able to scroll the keyboard shortcuts dialog
for a long time.
The problem is that firefox handles overflowing column content
differently to other browsers. Most browsers overflow *downwards*, but
firefox overflows *sideways*, and there's no CSS property to control
that behaviour.
### Change Type
- [x] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [ ] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. Open the keyboard shortcuts dialog on firefox.
2. Try to scroll the dialog to see overflowing content. More visible on
smaller screens.
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- Add a brief release note for your PR here.
Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
This PR fixes the position of the cursor chat bubble when the canvas is
not positioned at the top left.
### Change Type
- [x] `internal`
### Test Plan
1. Using CSS, add a margin left to the tldraw component on a multiplayer
route.
2. Use cursor chat.
### Release Notes
- Fixed a bug where cursor chat bubble position could be wrong when a
sidebar was open.
---------
Co-authored-by: Lu Wilson <l2wilson94@gmail.com>
Describe what your pull request does. If appropriate, add GIFs or images
showing the before and after.
### Change Type
- [ ] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [x] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [ ] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. Add a step-by-step description of how to test your PR here.
2.
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- Fix a link that was pointing to a 404 on GitHub
This PR provides some safe wrappers for local storage calls. Local
storage is not available in all environments (for example, a React
Native web view). The PR also adds an eslint rule preventing direct
calls to local / session storage.
### Change Type
- [x] `patch` — Bug fix
### Release Notes
- Fixes a bug that could cause crashes in React Native webviews.
My last PR added dependabot config. But it seems it only controls the
version updates, which we probably don't want for now. So I'm removing
this config for now. I guess security update frequency can't really be
configured since they are meant as urgent and should be merged asap?
### Change Type
- [ ] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [x] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
Adds dependabot config.
Seems like monthly is the least frequent update you can choose right now
(there are feature request for quarterly and for chron like syntax).
For now I used the daily interval though. I want to make sure it works,
will then switch to monthly. The main thing I'd like to see is that the
main `yarn.lock` file gets updated. That didn't happen in one of the
previous dependabot PRs (seems like [others faced the same
issue](https://github.com/dependabot/dependabot-core/issues/6346)). So 🤞
this solves it.
Also added a dedupe workflow, that should only run on dependabot
branches (prefixed with `depandabot/`). Otherwise we would need to
manually do it, as [seen on this
PR](https://github.com/tldraw/tldraw/pull/2982)
([failure](https://github.com/tldraw/tldraw/actions/runs/8070271847/job/22047204003)).
### Change Type
- [ ] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [x] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
Some of the tooling changes we made last week made it so that canary
releases were being published with the `latest` dist tag. This should
prevent that from happening, and I also fixed all the current packages
to set `latest` back to 2.0.0
### Change Type
- [ ] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [x] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
This PR:
- adds a simple custom shape example
- adds an interactive shape example
- updates editable shape example
closes TLD-2118
- [x] `documentation` — Changes to the documentation only[^2]
### Release Notes
- adds a simple custom shape example
- adds an interactive shape example
- updates editable shape example
---------
Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
This PR exposes a method for getting the style for the next shape.
### Change Type
- [x] `patch` — Bug fix
### Release Notes
- Expose the API for `Editor.getStyleForNextShape`, previously marked as
internal.
This PR adds a few guards against crashes when the video shape element
is not found.
### Change Type
- [x] `patch` — Bug fix
### Release Notes
- Fixed a rare crash with video shapes.
Adds an example of how to use tldraw styles in a custom shape
- [x] `documentation` — Changes to the documentation only[^2]
### Release Notes
- shape with tldraw styles example
---------
Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
This PR updates our end to end tests so that they check every route in
our examples to ensure that it loads (skipping any routes that don't
features a canvas).
### Change Type
- [x] `tests` — Changes to any test code only[^2]
### Test Plan
- [x] End to end tests
This PR adds a custom selection UI example.
It also fixes a bug with pageToScreen and adds a
`getSelectionRotatedScreenBounds` method.
### Change Type
- [ ] `patch` — Bug fix
- [x] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [ ] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Release Notes
- Adds selection UI example.
- Adds `Editor.getSelectionRotatedScreenBounds` method
- Fixes a bug with `pageToScreen`.
Describe what your pull request does. If appropriate, add GIFs or images
showing the before and after.
Follow up to #2987
### Change Type
- [x] `patch` — Bug fix
### Release Notes
- Prevent using randomness API at init time, to allow importing the
tldraw package in a cloudflare worker.
follow up to #3009
the versions.ts files were not being updated since things had been added
and moved around
### Change Type
- [ ] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [x] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. Add a step-by-step description of how to test your PR here.
2.
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- Add a brief release note for your PR here.
follow up to #3008
### Change Type
- [ ] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [x] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. Add a step-by-step description of how to test your PR here.
2.
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- Add a brief release note for your PR here.
Follow up to #3006
### Change Type
- [ ] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [x] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. Add a step-by-step description of how to test your PR here.
2.
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- Add a brief release note for your PR here.
