[pull] main from tldraw:main#565
Merged
Merged
Conversation
Seems I went a bit too quickly with the previous work on docs and canonical urls and actually removed the thing that makes the quick-start page actually work ### Change type - [x] `bugfix` - [ ] `improvement` - [ ] `feature` - [ ] `api` - [ ] `other`
## Summary
The latest few `tldraw@next` versions on npm ship with `"workspace:*"`
literals in their `package.json`, which breaks installs for any consumer
outside this monorepo:
```
$ yarn up tldraw@next
Error: @tldraw/driver@workspace:*: Workspace not found (@tldraw/driver@workspace:*)
```
Inspecting the broken tarball confirms the source `package.json`
(tab-indented, `workspace:*` deps) is shipped untouched:
```
$ npm pack tldraw@5.1.0-next.d83788c14b6f
$ tar -xzOf tldraw-5.1.0-next.d83788c14b6f.tgz package/package.json | grep '@tldraw/'
"@tldraw/driver": "workspace:*",
"@tldraw/editor": "workspace:*",
"@tldraw/store": "workspace:*",
```
Comparing to a prior good publish (`5.1.0-next.d7c83ba698ae`) shows the
expected output — 2-space-indented `package.json` with rewritten npm
versions. The registry metadata also tells the story:
| | Good (`d7c83ba698ae`) | Bad (`d83788c14b6f`) |
|---|---|---|
| `_npmUser` | `tldraw-personal <steve@tldraw.com>` | `GitHub Actions
<npm-oidc-no-reply@github.com>` |
| `_npmVersion` | (yarn) | `11.8.0` (npm CLI) |
| provenance | none | OIDC attestation |
## Root cause
PR #8913 swapped the publish call in
`internal/scripts/lib/publishing.ts` from `yarn npm publish` to `npm
publish`. The PR motivation — switching to npm's OIDC trusted-publisher
flow — was correct, but the swap had a silent side effect: `yarn npm
publish` rewrites `workspace:*` dependency specifiers into concrete
sibling versions during pack, and `npm publish` doesn't (the workspace
protocol is a yarn-specific extension that npm has no concept of).
The swap turns out to have been unnecessary. **Yarn 4.10**
([yarnpkg/berry#6898](yarnpkg/berry#6898), Oct
2025) added native OIDC trusted-publishing support. When `yarn npm
publish` runs in GitHub Actions with `permissions: id-token: write`
granted, yarn requests the GitHub-issued OIDC token, exchanges it with
the npm registry, and publishes — exactly like the npm CLI does.
Provenance attestations are produced automatically. This repo is already
on yarn 4.12 via the `packageManager` field, so OIDC was supported the
whole time #8913 was being written.
## Change
This PR reverts only the publish-call change from #8913 and updates the
surrounding comment to reflect the yarn-driven OIDC path. The
workflow-side changes from #8913 (`permissions: id-token: write` on each
publish job, removal of `NPM_TOKEN` env, trusted-publisher configuration
on npmjs.com) are unchanged and remain required.
`--tolerate-republish` is restored alongside the yarn invocation since
it's a yarn-specific flag; the substring-match catch block (added in
#8913 to compensate for npm CLI not having `--tolerate-republish`) is
kept as a belt-and-braces defense, because the original code comment
notes `--tolerate-republish` is unreliable for canary versions.
## Test plan
- [ ] Merge to `main` and watch `publish.yml` run `canary` mode
end-to-end on the next push to `main`.
- [ ] After publish, `npm pack <new-canary-version>` and confirm
dependency specifiers in the tarball's `package.json` show concrete
versions (e.g. `"@tldraw/editor": "5.1.0-canary.<sha>"`), not
`"workspace:*"`.
- [ ] Confirm the new canary version still shows a provenance
attestation badge on npmjs.com (yarn 4.10+ produces these automatically
under OIDC).
- [ ] In a consumer repo, run `yarn up tldraw@canary` and verify it
resolves without the "Workspace not found" error.
After this lands, the `5.1.0-next.*` versions published since #8913
merged are still broken on npm; the registry doesn't allow unpublishing
after 72 hours so they'll need to be left as-is, with the next good
`next` publish (post-merge) being the recommended upgrade target.
…review (#8964) In order to stop the "Deploy .com to preview" workflow from failing on the "Create Supabase preview branch" step, this PR makes the branch-provisioning wait loop tolerant of the Supabase CLI's output while a branch is still being created. The Supabase CLI [v2.102.0](https://github.com/supabase/cli/releases/tag/v2.102.0) [ported the `branches` commands from Go to native TypeScript](supabase/cli#5374). Because our workflow installs the CLI with `version: latest`, CI picked this up automatically. The rewrite changed what `supabase branches get -o json` writes to **stdout** while a branch is still provisioning: the old (Go) CLI wrote empty stdout there, but the new (TS) CLI renders a non-JSON error/status line. The workflow piped that straight into an unguarded `jq`, which exited with code 5 on the parse error, and since the step runs under `set -e` the whole step aborted on the first loop iteration — before the retry loop could wait for the branch to become ready. This was a CLI behavior change, not a regression in our code: the script had been unchanged since the [Supabase preview-DB migration](#8066), and the same workflow passed on older CLI versions. The fix adds `2>/dev/null || true` to `supabase branches get` and to both `jq` calls so that, while the branch is provisioning, non-JSON / non-zero output is treated as "not ready yet" and the loop keeps retrying as it was always meant to. Once the branch is ready the CLI returns valid JSON, `jq` extracts `POSTGRES_URL`, and the loop breaks normally. Field names (`POSTGRES_URL`, `POSTGRES_URL_NON_POOLING`) are unchanged in the new CLI, so no other adjustments are needed, and the CLI stays on `latest`. ### Change type - [x] `other` (CI) ### Test plan 1. Open a PR that triggers the "Deploy .com to preview" workflow with a brand-new preview branch (one that has to provision from scratch). 2. Confirm the "Create Supabase preview branch" step logs "Waiting for branch to be ready (i/24)..." while provisioning and then succeeds, instead of failing with `jq: parse error` / exit code 5. ### Code changes | Section | LOC change | | -------------- | ---------- | | Config/tooling | +8 / -3 |
In order to let pre-commit hooks run cleanly from inside git worktrees, this PR bumps `oxlint` from 1.58.0 to 1.66.0. ### The bug When a worktree lives under the main repo (for example `.claude/worktrees/<name>/`), oxlint 1.58 walks up from the file being linted, finds the worktree's `.oxlintrc.json`, and then keeps walking and also finds the main repo's `.oxlintrc.json`. It treats one of the two identical configs as a "nested" config and rejects `options.typeAware`: ``` The `options.typeAware` option is only supported in the root config, but it was found in /Users/.../.oxlintrc.json ``` The net effect: the lint-staged step in `.husky/pre-commit` blows up for every commit made from inside a worktree, regardless of what the diff is, which forces contributors (and Claude Code agents) to use `git commit --no-verify`. ### The fix Upstream fixed this in oxlint 1.64 — [oxc-project/oxc#22272](oxc-project/oxc#22272) ("load root config by searching up parent directories"). Bumping to 1.66 (latest available in our registry mirror) picks up the fix at the source. No config or script changes needed. The earlier commit on this branch added a `--disable-nested-config` workaround flag to `lint-staged` and `internal/scripts/lint.ts`; the follow-up commit reverts it now that the bump makes it unnecessary. ### Change type - [x] `other` ### Test plan 1. `git worktree add .claude/worktrees/test-worktree` 2. `cd .claude/worktrees/test-worktree && yarn install` 3. `yarn oxlint packages/tldraw/src/lib/ui/hooks/useClipboardEvents.ts` — exits 0, no `options.typeAware` parse error. 4. Make any trivial change inside the worktree, `git add` it, and `git commit` (without `--no-verify`) — pre-commit hook completes cleanly. ### Code changes | Section | LOC change | | -------------- | ------------ | | Config/tooling | +85 / -85 | (`package.json` +1 / -1, `yarn.lock` +84 / -84.)
Closes #8965 ## What Dotcom previews now always deploy a single-node Zero backend, so the `@tldraw.com` "proper Zero" opt-in is valid on every preview. Previously a plain `dotcom-preview-please` deploy set `DEPLOY_ZERO=false` unless the `preview-flyio-zero-deploy-please` label was present, but the client still opted any `@tldraw.com` user into proper Zero — pointing staff at the placeholder backend `zero-backend-not-deployed.tldraw.com`, which doesn't exist for the preview. This takes option 2 from the issue (deploy Zero for previews) rather than gating the opt-in client-side. ## Changes - **`.github/workflows/deploy-dotcom.yml`** — "Determine zero deploy target": any PR preview now sets `DEPLOY_ZERO=flyio` (single-node). Removed the `preview-flyio-zero-deploy-please` label check, the commented-out auto-label block, and the diff-based `apps/dotcom/` fallback that resolved to `false`. `production`/`main` stay on `flyio-multinode`. - **`internal/scripts/deploy-dotcom.ts`** — `getZeroUrl()` preview case now always returns the deployed fly URL; removed the dead `zero-backend-not-deployed` preview branch. ## Pruning / cleanup No prune changes needed: each preview creates `pr-<n>-zero-cache`, which already matches `prune-preview-deploys.ts`'s `ZERO_CACHE_APP_REGEX` and is destroyed daily once the PR has been closed for >2 days. ## Follow-ups - Delete the now-unused `preview-flyio-zero-deploy-please` GitHub label (not referenced anywhere in code). - Every dotcom preview now provisions a fly `zero-cache` app + runs Zero migrations against its Supabase branch DB — small added per-preview cost/latency. ## Test plan 1. Open a PR and apply `dotcom-preview-please`. 2. Sign into the preview with a `@tldraw.com` account. 3. Confirm the console logs `[Zero] Using proper Zero (@tldraw.com email)` against the preview's `pr-<n>-zero-cache.fly.dev` backend and that Zero-backed features work.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )