For non-commercial usage of tldraw, this adds a watermark in the corner,
both for branding purposes and as an incentive for our enterprise
customers to purchase a license.
For commercial usage of tldraw, you add a license to the `<Tldraw
licenseKey={YOUR_LICENSE_KEY} />` component so that the watermark
doesn't show.
The license is a signed key that has various bits of information in it,
such as:
- license type
- hosts that the license is valid for
- whether it's an internal-only license
- expiry date
We check the license on load and show a watermark (or throw an error if
internal-only) if the license is not valid in a production environment.
This is a @MitjaBezensek, @Taha-Hassan-Git, @mimecuvalo joint
production! 🤜🤛
### Change Type
<!-- ❗ Please select a 'Scope' label ❗️ -->
- [x] `sdk` — Changes the tldraw SDK
- [ ] `dotcom` — Changes the tldraw.com web app
- [ ] `docs` — Changes to the documentation, examples, or templates.
- [ ] `vs code` — Changes to the vscode plugin
- [ ] `internal` — Does not affect user-facing stuff
<!-- ❗ Please select a 'Type' label ❗️ -->
- [ ] `bugfix` — Bug fix
- [x] `feature` — New feature
- [ ] `improvement` — Improving existing features
- [ ] `chore` — Updating dependencies, other boring stuff
- [ ] `galaxy brain` — Architectural changes
- [ ] `tests` — Changes to any test code
- [ ] `tools` — Changes to infrastructure, CI, internal scripts,
debugging tools, etc.
- [ ] `dunno` — I don't know
### Test Plan
1. We will be dogfooding on staging.tldraw.com and tldraw.com itself
before releasing this.
### Release Notes
- SDK: wires up tldraw to have licensing mechanisms.
---------
Co-authored-by: Mitja Bezenšek <mitja.bezensek@gmail.com>
Co-authored-by: Taha <98838967+Taha-Hassan-Git@users.noreply.github.com>
Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
Fixes asset loading/processing on staging/previews by introducing a new
image processing worker. This worker acts as a proxy for our various
image hosts and resizes/optimizes/caches images on the fly. Like the old
bookmark worker, this one is deployed in an ad-hoc fashion as it works
across environments and we're not likely to change it often.
### Change type
- [x] `other`
Adds an assets server to the demo worker, and reworks the existing asset
server to use the same code. There are a few simplifications to the code
due to some DX improvements working with R2 and caches. I also removed
the `HEAD` request from the assets server: i took a look at our logs and
it's not actually used at all.
This also fixes an issue where users could overwrite the contents of the
asset uploads bucket.
### Change type
- [x] `other`
Sets up preview deploys etc. for bemo worker.
There's enough going on here that I wanted to make it its own PR. I'll
rework david's spike on top of it once it's landed.
### Change Type
- [x] `internal` — Does not affect user-facing stuff
- [x] `chore` — Updating dependencies, other boring stuff
---------
Co-authored-by: David Sheldrick <d.j.sheldrick@gmail.com>
This PR aims to make sure #4030 doesn't need to happen again. We check
that the worker file sizes stay within a given limit, and require people
to explicitly up this limit if they decide to add new deps that grow the
bundle size significantly.
### Change Type
<!-- ❗ Please select a 'Type' label ❗️ -->
- [ ] `feature` — New feature
- [ ] `improvement` — Product improvement
- [ ] `api` — API change
- [ ] `bugfix` — Bug fix
- [x] `other` — Changes that don't affect SDK users, e.g. internal or
.com changes
### 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 PR replaces the extendable TLServer class with an instantiatable
wrapper for the TLSyncRoom called TLSocketRoom.
The goal is to provide an API where you pretty much just
1. create a room from some (optional) snapshot
2. pass websockets into it when they connect
And then lifecycle stuff and persistence stuff is left to the consumer,
since that all seems to be much more context dependent.
One thing remaining here is to work on observability. We had a slightly
messy situation regarding logging and error handling and analytics and I
want to clean that all up.
### Change Type
<!-- ❗ Please select a 'Scope' label ❗️ -->
- [ ] `sdk` — Changes the tldraw SDK
- [ ] `dotcom` — Changes the tldraw.com web app
- [ ] `docs` — Changes to the documentation, examples, or templates.
- [ ] `vs code` — Changes to the vscode plugin
- [x] `internal` — Does not affect user-facing stuff
<!-- ❗ Please select a 'Type' label ❗️ -->
- [ ] `bugfix` — Bug fix
- [ ] `feature` — New feature
- [ ] `improvement` — Improving existing features
- [ ] `chore` — Updating dependencies, other boring stuff
- [x] `galaxy brain` — Architectural changes
- [ ] `tests` — Changes to any test code
- [ ] `tools` — Changes to infrastructure, CI, internal scripts,
debugging tools, etc.
- [ ] `dunno` — I don't know
### Test Plan
1. Add a step-by-step description of how to test your PR here.
4.
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- Add a brief release note for your PR here.
This is a followup to https://github.com/tldraw/tldraw/pull/3112 after a
discussion with Alex about how our release notes writing is really
manual now.
This changes the labels to be a more limited set.
It also adds a plugin to help massage the release notes into what we
want it to be:
- ignores bot commits
- use the release notes, if found, not the commit msg
- skip writing the "release notes" in general, just create the changelog
which is what we want anyway.
### Change Type
<!-- ❗ Please select a 'Scope' label ❗️ -->
- [ ] `sdk` — Changes the tldraw SDK
- [ ] `dotcom` — Changes the tldraw.com web app
- [ ] `docs` — Changes to the documentation, examples, or templates.
- [ ] `vs code` — Changes to the vscode plugin
- [ ] `internal` — Does not affect user-facing stuff
<!-- ❗ Please select a 'Type' label ❗️ -->
- [ ] `bugfix` — Bug fix
- [ ] `feature` — New feature
- [ ] `improvement` — Improving existing features
- [ ] `chore` — Updating dependencies, other boring stuff
- [ ] `galaxy brain` — Architectural changes
- [ ] `tests` — Changes to any test code
- [ ] `tools` — Changes to infrastructure, CI, internal scripts,
debugging tools, etc.
- [ ] `dunno` — I don't know
VS Code extension can do
[pre-releases](https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions).
This would make it easier to test unreleased version of the extension
(thanks @ds300 [for the
suggestion](https://github.com/tldraw/tldraw/pull/3905#pullrequestreview-2122897351))
Tried the pre-release option manually, to see how it works:
https://github.com/tldraw/tldraw/assets/2523721/880fe0a2-3f29-405b-9862-b30594cf5334
There's a drawback in that we need to update version even for
pre-releases as they do not support other versioning schemes atm. I
decided to go with patch versions for pre-releases and minor versions
for regular releases. Feels like a better UX than having a really high
patch number due to bumping it on every PR.
> We only support major.minor.patch for extension versions, semver
pre-release tags are not supported. So, if you publish a
major.minor.patch-tag release to the Marketplace, it will be treated as
major.minor.patch, and the tag will be ignored. Versions must be
different between pre-release and regular releases. That is, if 1.2.3 is
uploaded as a pre-release, the next regular release must be uploaded
with a distinct version, such as 1.2.4. Full semver support will be
available in the future.
### Change Type
<!-- ❗ Please select a 'Scope' label ❗️ -->
- [ ] `sdk` — Changes the tldraw SDK
- [ ] `dotcom` — Changes the tldraw.com web app
- [ ] `docs` — Changes to the documentation, examples, or templates.
- [x] `vs code` — Changes to the vscode plugin
- [ ] `internal` — Does not affect user-facing stuff
<!-- ❗ Please select a 'Type' label ❗️ -->
- [ ] `bugfix` — Bug fix
- [ ] `feature` — New feature
- [ ] `improvement` — Improving existing features
- [ ] `chore` — Updating dependencies, other boring stuff
- [ ] `galaxy brain` — Architectural changes
- [ ] `tests` — Changes to any test code
- [x] `tools` — Changes to infrastructure, CI, internal scripts,
debugging tools, etc.
- [ ] `dunno` — I don't know
### Release Notes
- Release a pre-release when we merge changes to main.
Added a new environment called `vsce publish` and added the VSCE_PAT
secret to it.
### Change Type
<!-- ❗ Please select a 'Scope' label ❗️ -->
- [ ] `sdk` — Changes the tldraw SDK
- [ ] `dotcom` — Changes the tldraw.com web app
- [ ] `docs` — Changes to the documentation, examples, or templates.
- [x] `vs code` — Changes to the vscode plugin
- [ ] `internal` — Does not affect user-facing stuff
<!-- ❗ Please select a 'Type' label ❗️ -->
- [ ] `bugfix` — Bug fix
- [ ] `feature` — New feature
- [ ] `improvement` — Improving existing features
- [ ] `chore` — Updating dependencies, other boring stuff
- [ ] `galaxy brain` — Architectural changes
- [x] `tests` — Changes to any test code
- [ ] `tools` — Changes to infrastructure, CI, internal scripts,
debugging tools, etc.
- [ ] `dunno` — I don't know
### Release Notes
- Introduce a new CI environment and use it for publishing vs code
extension.
When pushing to production branch we now also package and publish a new
version of the VS Code extension. We get the last version from VS Code
marketplace and update the package.json with that version. We don't
commit that to the repo though (see the discussion below).
I added `VSCE_PAT` secret (my own personal access token from the
dev.azure.com), which will expire in 1 year. This is used when running
the publish command.
Some more info here:
- [Publishing from
CI](https://code.visualstudio.com/api/working-with-extensions/continuous-integration#github-actions)
- Publishing uses `VSCE_PAT` env variable
### Change Type
<!-- ❗ Please select a 'Scope' label ❗️ -->
- [ ] `sdk` — Changes the tldraw SDK
- [ ] `dotcom` — Changes the tldraw.com web app
- [ ] `docs` — Changes to the documentation, examples, or templates.
- [x] `vs code` — Changes to the vscode plugin
- [ ] `internal` — Does not affect user-facing stuff
<!-- ❗ Please select a 'Type' label ❗️ -->
- [ ] `bugfix` — Bug fix
- [ ] `feature` — New feature
- [ ] `improvement` — Improving existing features
- [ ] `chore` — Updating dependencies, other boring stuff
- [ ] `galaxy brain` — Architectural changes
- [ ] `tests` — Changes to any test code
- [x] `tools` — Changes to infrastructure, CI, internal scripts,
debugging tools, etc.
- [ ] `dunno` — I don't know
### Release Notes
- Automate publishing of the VS Code extension.
We have to make sure that env variables are present.
Might be better to use `makeEnv` inside these workflows instead of just
inside `upload-static-assets`? Feels repetitive though.
### Change Type
<!-- ❗ Please select a 'Scope' label ❗️ -->
- [ ] `sdk` — Changes the tldraw SDK
- [ ] `dotcom` — Changes the tldraw.com web app
- [ ] `docs` — Changes to the documentation, examples, or templates.
- [ ] `vs code` — Changes to the vscode plugin
- [x] `internal` — Does not affect user-facing stuff
<!-- ❗ Please select a 'Type' label ❗️ -->
- [x] `bugfix` — Bug fix
- [ ] `feature` — New feature
- [ ] `improvement` — Improving existing features
- [ ] `chore` — Updating dependencies, other boring stuff
- [ ] `galaxy brain` — Architectural changes
- [ ] `tests` — Changes to any test code
- [ ] `tools` — Changes to infrastructure, CI, internal scripts,
debugging tools, etc.
- [ ] `dunno` — I don't know
### Release Notes
- Fix an issue with uploading the static assets.
this is take #2 of this PR https://github.com/tldraw/tldraw/pull/3764
This continues the idea kicked off in
https://github.com/tldraw/tldraw/pull/3684 to explore LOD and takes it
in a different direction.
Several things here to call out:
- our dotcom version would start to use Cloudflare's image transforms
- we don't rewrite non-image assets
- we debounce zooming so that we're not swapping out images while
zooming (it creates jank)
- we load different images based on steps of .25 (maybe we want to make
this more, like 0.33). Feels like 0.5 might be a bit too much but we can
play around with it.
- we take into account network connection speed. if you're on 3g, for
example, we have the size of the image.
- dpr is taken into account - in our case, Cloudflare handles it. But if
it wasn't Cloudflare, we could add it to our width equation.
- we use Cloudflare's `fit=scale-down` setting to never scale _up_ an
image.
- we don't swap the image in until we've finished loading it
programatically (to avoid a blank image while it loads)
TODO
- [x] We need to enable Cloudflare's pricing on image transforms btw
@steveruizok 😉 - this won't work quite yet until we do that.
### Change Type
<!-- ❗ Please select a 'Scope' label ❗️ -->
- [x] `sdk` — Changes the tldraw SDK
- [ ] `dotcom` — Changes the tldraw.com web app
- [ ] `docs` — Changes to the documentation, examples, or templates.
- [ ] `vs code` — Changes to the vscode plugin
- [ ] `internal` — Does not affect user-facing stuff
<!-- ❗ Please select a 'Type' label ❗️ -->
- [ ] `bugfix` — Bug fix
- [x] `feature` — New feature
- [ ] `improvement` — Improving existing features
- [ ] `chore` — Updating dependencies, other boring stuff
- [ ] `galaxy brain` — Architectural changes
- [ ] `tests` — Changes to any test code
- [ ] `tools` — Changes to infrastructure, CI, internal scripts,
debugging tools, etc.
- [ ] `dunno` — I don't know
### Test Plan
1. Test images on staging, small, medium, large, mega
2. Test videos on staging
- [x] Unit Tests
- [ ] End to end tests
### Release Notes
- Assets: make option to transform urls dynamically to provide different
sized images on demand.
This PR includes a "soft preload" feature for icons, where icons will be
loaded when the canvas first mounts. The component will not wait for
icons to finish loading before showing the editor, but this should help
with "pop in" on menu icons.
### Change Type
- [x] `sdk` — Changes the tldraw SDK
- [x] `improvement` — Improving existing features
### Test Plan
1. Load the component
2. After load, open a menu for the first time
3. The icons should immediately be visible
### Release Notes
- Improve icon preloading
Currently, we only use native `structuredClone` in the browser, falling
back to `JSON.parse(JSON.stringify(...))` elsewhere, despite Node
supporting `structuredClone` [since
v17](https://developer.mozilla.org/en-US/docs/Web/API/structuredClone)
and Cloudflare Workers supporting it [since
2022](https://blog.cloudflare.com/standards-compliant-workers-api/).
This PR adjusts our shim to use the native `structuredClone` on all
platforms, if available.
Additionally, `jsdom` doesn't implement `structuredClone`, a bug [open
since 2022](https://github.com/jsdom/jsdom/issues/3363). This PR patches
`jsdom` environment in all packages/apps that use it for tests.
Also includes a driveby removal of `deepCopy`, a function that is
strictly inferior to `structuredClone`.
### Change Type
<!-- ❗ Please select a 'Scope' label ❗️ -->
- [x] `sdk` — Changes the tldraw SDK
- [x] `dotcom` — Changes the tldraw.com web app
- [ ] `docs` — Changes to the documentation, examples, or templates.
- [ ] `vs code` — Changes to the vscode plugin
- [ ] `internal` — Does not affect user-facing stuff
<!-- ❗ Please select a 'Type' label ❗️ -->
- [ ] `bugfix` — Bug fix
- [ ] `feature` — New feature
- [x] `improvement` — Improving existing features
- [x] `chore` — Updating dependencies, other boring stuff
- [ ] `galaxy brain` — Architectural changes
- [ ] `tests` — Changes to any test code
- [ ] `tools` — Changes to infrastructure, CI, internal scripts,
debugging tools, etc.
- [ ] `dunno` — I don't know
### Test Plan
1. A smoke test would be enough
- [ ] Unit Tests
- [x] End to end tests
This PR switches up how PR labels are validated to allow for more
freeform label tweaking in the future. Basically **huppy will now only
check that your PR is labelled, it doesn't care how it's labelled**. I
also updated the PR template with a new labelling scheme that we can
tweak over time.
So before Huppy bot had to know about the specific set of allowed
labels, and now as long as the label exists you're allowed to add it.
So to add a new label to the PR template, just create the label and then
add an option for it in the .md file.
### 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
Before this PR all .md files were targeted by the `.ignore` file, which
has bitten me on a number of occasions since .md files often contain
valuable information (e.g. the vscode extensions docs). This PR
unignores .md files while still ignoring _generated_ .md files like our
changelogs, the api-report files, and the generated docs sections.
Additionally, the `yarn format` and `yarn lint` commands were configured
slightly differently, which was confusing, so I've unified those and
simplified the lint.ts script at the same time.
### 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 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.
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
Rename `@tldraw/tldraw` to just `tldraw`! `@tldraw/tldraw` still exists
as an alias to `tldraw` for folks who are still using that.
### Test Plan
- [x] Unit Tests
- [ ] End to end tests
### Release Notes
- The `@tldraw/tldraw` package has been renamed to `tldraw`. You can
keep using the old version if you want though!
Bring back the template publishing stuff, now with a problem fixed
https://github.com/tldraw/tldraw/pull/2999
### Change Type
- [x] `internal` — Any other changes that don't affect the published
package
@si14 this template publish thing was failing, i think you referenced
the workflow incorrectly, I'm just gonna comment out for now, take a
look when you have time
https://github.com/tldraw/tldraw/actions/runs/8096363547
### 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.
Gonna merge in a sneaky dry run mode to test the args parsing etc
### 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.
The idea here is to mirror project templates from our monorepo to the
corresponding "top level" repos in our organisation. The main benefits
are:
- being able to easily synchronise template versions to the last release
on release
- being able to test those templates together with the rest of the
project
- being able to deploy the unreleased version of the templates
However, this PR will only do the synchronisation part. The main
roadblock for the latter at the moment is running `yarn install` on
packages in the current `main` that are still unreleased. There are ways
around that, but this PR is deliberately minimalistic to land it sooner.
### Change Type
- [x] `internal` — Any other changes that don't affect the published
package
---------
Co-authored-by: Taha <98838967+Taha-Hassan-Git@users.noreply.github.com>
Closes#2800
This PR makes it so that `check-scripts` will error out if you forget to
add a "references" entry to a tsconfig file when adding an internal
dependency in our monorepo.
If these project references are missed it can prevent TS from
building/rebuilding things when they need to be built/rebuilt.
### Change Type
- [x] `internal` — Any other changes that don't affect the published
package[^2]
As discussed offline, just making `yarn test` do what we expect it to.
### Change Type
- [x] `internal` — Any other changes that don't affect the published
package[^2]
Biome as it is now didn't work out for us 😢
Summary for posterity:
* it IS much, much faster, fast enough to skip any sort of caching
* we couldn't fully replace Prettier just yet. We use Prettier
programmatically to format code in docs, and Biome's JS interface is
officially alpha and [had legacy peer deps
set](https://github.com/biomejs/biome/pull/1756) (which would fail our
CI build as we don't allow installation warnings)
* ternary formatting differs from Prettier, leading to a large diff
https://github.com/biomejs/biome/issues/1661
* import sorting differs from Prettier's
`prettier-plugin-organize-imports`, making the diff even bigger
* the deal breaker is a multi-second delay on saving large files (for us
it's
[Editor.ts](https://github.com/tldraw/tldraw/blob/main/packages/editor/src/lib/editor/Editor.ts))
in VSCode when import sorting is enabled. There is a seemingly relevant
Biome issue where I posted a small summary of our findings:
https://github.com/biomejs/biome/issues/1569#issuecomment-1930411623
Further actions:
* reevaluate in a few months as Biome matures
### Change Type
- [x] `internal` — Any other changes that don't affect the published
package
Biome seems to be MUCH faster than Prettier. Unfortunately, it
introduces some formatting changes around the ternary operator, so we
have to update files in the repo. To make revert easier if we need it,
the change is split into two PRs. This PR introduces a Biome CI check
and reformats all files accordingly.
## Change Type
- [x] `minor` — New feature
Biome seems to be MUCH faster than Prettier. Unfortunately, it
introduces some formatting changes around the ternary operator, so we
have to update files in the repo. To make revert easier if we need it,
the change is split into two PRs. This PR has only config/package
changes and is expected to fail the CI.
## Change Type
- [x] `minor` — New feature
The script that prunes old preview deployments in cloudlfare was broken
when we moved dotcom into the public repo. This fixes it.
### Change Type
- [x] `internal` — Any other changes that don't affect the published
package[^2]
This PR introduces a new Cloudflare worker for health checks.
At the moment the worker only translates Updown webhooks into Discord
webhooks. In the future we can teach this worker to check more things.
### Change Type
- [x] `internal` — Any other changes that don't affect the published
package
---------
Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
This PR adds an issue template to request an example on the repo. And
adds a button to the examples app to request an example.
I've added a blue background to the view code button to distinguish it
from the request example. I think it makes the most sense as our primary
button for the page.
### 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
### Release Notes
- Add a button to request an example to the examples app
---------
Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
This PR removes our "original tldraw issue" contact link, replacing it
with a docs link.
### 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
`github.event.ref` is only there on certain events, but `github.ref` is
always there
### Change Type
- [x] `internal` — Any other changes that don't affect the published
package[^2]
This PR moves the tldraw.com app into the public repo.
### Change Type
- [x] `internal` — Any other changes that don't affect the published
package[^2]
---------
Co-authored-by: Dan Groshev <git@dgroshev.com>
Co-authored-by: alex <alex@dytry.ch>
