Move tests to closed source repo

[steveruizok]

Move the test suite out of the open source tldraw/tldraw repo and into the closed source repo.

Context

The tldraw monorepo currently contains ~327 test files across unit, integration, and e2e tests:

• packages/tldraw: ~148 unit/integration tests (shapes, tools, commands, UI)
• packages/editor: ~41 unit/integration tests (geometry, managers, tools)
• packages/store: ~27 unit tests (records, queries, migrations)
• packages/utils: ~30 unit tests (array, cache, media, hashing)
• packages/sync-core: ~20 unit/integration tests (room, storage, protocol)
• packages/state: ~12 unit tests (atoms, computed, transactions)
• packages/tlschema: ~9 unit tests (schema, migrations)
• packages/validate: ~2 unit tests
• packages/sync: ~2 unit tests
• apps/examples/e2e: ~24 Playwright e2e tests
• apps/dotcom/client/e2e: ~12 Playwright e2e tests

Scope

• Move all vitest unit/integration tests
• Move all Playwright e2e tests
• Move test configuration (vitest configs, playwright configs, test setup files)
• Move test utilities and helpers (e.g. TestEditor)
• Ensure CI in the closed source repo runs the full test suite against the SDK packages
• Remove test files from the open source repo

[steveruizok]

Research notes

Test file counts (~327 files total)

Location	Count	Type	Framework
packages/tldraw/src	~148	Unit/Integration	Vitest (jsdom)
packages/editor/src	~41	Unit/Integration	Vitest (jsdom)
packages/utils/src	~30	Unit	Vitest (jsdom)
packages/store/src	~27	Unit	Vitest (node)
packages/sync-core/src	~20	Unit/Integration	Vitest (node)
packages/state/src	~12	Unit	Vitest (node)
packages/tlschema/src	~9	Unit	Vitest (node)
packages/validate/src	~2	Unit	Vitest (node)
packages/sync/src	~2	Unit	Vitest (jsdom)
apps/examples/e2e	~24	E2E	Playwright
apps/dotcom/client/e2e	~12	E2E	Playwright

Configuration to move

Vitest configs (24 total):

• Root: vitest.config.ts
• Shared preset: internal/config/vitest/node-preset.ts
• Shared setup: internal/config/vitest/setup.ts (custom matchers, polyfills)
• Per-package: packages/*/vitest.config.ts
• Per-app: apps/*/vitest.config.ts, apps/dotcom/*/vitest.config.ts

Setup files (package-specific polyfills):

• packages/editor/setupVitest.js — IndexedDB, ResizeObserver, Crypto, FontFace, PointerEvent, DragEvent, etc.
• packages/tldraw/setupVitest.js — all editor polyfills + breakpoint/translation mocks, getComputedStyle, font request mocking
• packages/utils/setupVitest.js, packages/sync/setupVitest.js, packages/sync-core/setupVitest.js
• packages/store/setupTests.js, apps/dotcom/client/setupTests.js

Playwright configs (2):

• apps/examples/e2e/playwright.config.ts
• apps/dotcom/client/playwright.config.ts
• Plus global setup/teardown files and shared utilities

Shared test utilities

• packages/editor/src/lib/test/TestEditor.ts — base TestEditor class
• packages/tldraw/src/test/TestEditor.ts — extended TestEditor with full defaults
• packages/tldraw/src/test/testutils/ — renderTldrawComponent, getSnapLines, pretty, roundedBox
• packages/tldraw/src/test/test-jsx.tsx — JSX shape creation helpers
• packages/tldraw/src/test/drawing.data.ts — test data fixtures

CI workflows

• .github/workflows/checks.yml — runs yarn test-ci (vitest)
• .github/workflows/playwright-examples.yml — examples E2E
• .github/workflows/playwright-dotcom.yml — dotcom E2E (with Clerk auth)
• .github/workflows/staging-e2e.yml — staging E2E

Key dependencies

Unit tests: vitest, @vitest/coverage-v8, jsdom, vitest-canvas-mock, @testing-library/react, @testing-library/dom, @jest/expect-utils, jest-matcher-utils, fake-indexeddb, @peculiar/webcrypto, resize-observer-polyfill

E2E tests: @playwright/test, @clerk/testing/playwright (dotcom only)

Config inheritance chain

internal/config/vitest/node-preset.ts  (base config)
  └─ internal/config/vitest/setup.ts   (global setup: matchers, polyfills)
     └─ packages/*/vitest.config.ts    (per-package: environment, fake timers, CSS)
        └─ packages/*/setupVitest.js   (per-package: DOM polyfills, mocks)

Root vitest.config.ts aggregates all workspace configs as vitest projects.

[hushino]

being scared from the AI is no the way to go, I suggest you go completely closed source and not be lukewarm, and for the tests I hope in any case they return to open source when the trend passes

[EzzatOmar]

lol, 6 months from now ai will one shot tldraw like apps

hiding the tests will not prevent that

[Tsurgcom]

So no more new tests?

Also, this is ironic

[verdverm]

Have you considered

1. That we can use agents to run the software and generate a test suite, likely of equal or higher quality
2. That this decision might backfire and another year or two will render it meaningless (see 1)
3. The Streisand Effect has been activated by the very creation of this issue

[OriginalFork]

Have you considered

1. That we can use agents to run the software and generate a test suite, likely of equal or higher quality
2. That this decision might backfire and another year or two will render it meaningless (see 1)
3. The Streisand Effect has been activated by the very creation of this issue

I'm confused. If the AI folks think that AI would be able to one-shot the test or the applications why are y'all complaining about it. Shouldn't y'all go ahead and do it?

[jonasfroeller]

Have you considered

1. That we can use agents to run the software and generate a test suite, likely of equal or higher quality
2. That this decision might backfire and another year or two will render it meaningless (see 1)
3. The Streisand Effect has been activated by the very creation of this issue

I'm confused. If the AI folks think that AI would be able to one-shot the test or the applications why are y'all complaining about it. Shouldn't y'all go ahead and do it?

I mean it would definitely be more expensive

[verdverm]

after the Citrini story and the "look ma, no hands" reimplementation of both a browser and a framework, people are spooked and (over?) reacting, though I suppose there was a good probability someone would be the first to do this (though they haven't actually yet)

we are definitely racing ahead at full steam into the greatest unknowns any of us have ever seen

[ild0tt0re]

I understand your concerns, but I think this is the least effective solution.

[steveruizok]

Sorry folks, this issue was more of a joke (am I allowed to do that?) but I'll keep the issue open since there's some discussion here. Writing from mobile

• moving our tests into another repo would complicate and slow down our development, and speed for us is more important than ever
• more canvas better, I know for sure that our decisions have inspired other products and that's fine and good
• tldraw itself may eventually be a vibe coded alternative to tldraw
• the value is in the ability to produce new and good product decisions for users / customers, however you choose to create the code

tldraw's whole raison d'être is to make the canvas possible for future products. I started the company because I thought the "collaborative infinite canvas" paradigm could be used in so many more places, if only it weren't so difficult to build and maintain.

We sell a solution for that. If a developer wants to build a product that involves a canvas, then our tech helps them get closer to the application they want to build. And I think we've been on the market long enough that an infinite canvas feels more possible than it used to, or is an option in a way that it might not have been without us, if building a canvas app also meant building the whole damn canvas.

Even though we sell a product and I want that product to succeed, my line is always "more canvas better". This is a new product category. It isn't the first thing that comes to mind for software designers, so half of the job is just getting folks excited about the canvas. We've seen so much adoption because other products have done well. Figma introduces more and more people to how good the infinite canvas is. Excalidraw has inspired so many developers who end up building with tldraw. React flow is crushing it and half of our customers started there. Miro's big-tent PMF has inspired teams to build their own canvas experience for their own vertical, and many of those are doing it with our tech. More canvas better.

Anyway, there are absolutely going to be developers or teams who are able to make infinite canvas infrastructure with AI. I think they should: canvas is great, everyone should try it and should develop a kind of taste for the decisions involved. I mean that sincerely, not as a "you'll see how hard it is" toldyaso.

The companies who we sell to are looking to own less of their stack in order to focus on the parts that really matter. Opportunity costs, buy vs. build, etc. To be considered, our tldraw product needs to be excellent, cohesively designed, and seriously maintained. At the moment I don't think that any of those teams would prefer to have a vibe coded internal alternative, any more than they would a human-coded internal alternative, because most are trying to buy focus.

On the other hand, even if and when AI coding could produce a full canvas + backend, we might still find ourselves the high-taste stewards of an AI code factory, producing a canvas product and providing guarantees for its quality and fitness. However we produce the code, it will continue to embed our opinions about how best to deliver this experience for users and developers, as well as my incredibly fine opinions about arrows and ink, which are arbitrary but good and imo correct.

[marcindulak]

Rich Hickey said this about tests in 2011 https://www.youtube.com/watch?v=SxdOUGdseq4#t=16m08s. This observation applies to the week’s belief that production software can be created using tests and the nondeterministic behavior of LLMs.

I think we're in this world, I like to call guardrail programming. Right. It's really sad. We're like, I can make change cause I have tests. Right? Who does that? Who drives their car around banging against the guardrails, saying whoa, I'm glad I've got these guardrails because I'd never make it to the show on time.

[CalibanWsb]

Even if Steve joked, tests are important since they describe the specification. Without thoughtful tests the application will collapse under LLM hallucinations. It's definitely a valid strategy to avoid the laziest slop-forks.