PrivateCoffee/tldraw
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1
tldraw/packages/tlschema/api/api.json

9999 lines
319 KiB
JSON
Raw Normal View History

Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
{
"metadata": {
"toolPackage": "@microsoft/api-extractor",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"toolVersion": "7.43.1",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"schemaVersion": 1011,
"oldestForwardsCompatibleVersion": 1001,
"tsdocConfig": {
"$schema": "https://developer.microsoft.com/json-schemas/tsdoc/v0/tsdoc.schema.json",
"noStandardTags": true,
"tagDefinitions": [
{
"tagName": "@alpha",
"syntaxKind": "modifier"
},
{
"tagName": "@beta",
"syntaxKind": "modifier"
},
{
"tagName": "@defaultValue",
"syntaxKind": "block"
},
{
"tagName": "@decorator",
"syntaxKind": "block",
"allowMultiple": true
},
{
"tagName": "@deprecated",
"syntaxKind": "block"
},
{
"tagName": "@eventProperty",
"syntaxKind": "modifier"
},
{
"tagName": "@example",
"syntaxKind": "block",
"allowMultiple": true
},
{
"tagName": "@experimental",
"syntaxKind": "modifier"
},
{
"tagName": "@inheritDoc",
"syntaxKind": "inline"
},
{
"tagName": "@internal",
"syntaxKind": "modifier"
},
{
"tagName": "@label",
"syntaxKind": "inline"
},
{
"tagName": "@link",
"syntaxKind": "inline",
"allowMultiple": true
},
{
"tagName": "@override",
"syntaxKind": "modifier"
},
{
"tagName": "@packageDocumentation",
"syntaxKind": "modifier"
},
{
"tagName": "@param",
"syntaxKind": "block",
"allowMultiple": true
},
{
"tagName": "@privateRemarks",
"syntaxKind": "block"
},
{
"tagName": "@public",
"syntaxKind": "modifier"
},
{
"tagName": "@readonly",
"syntaxKind": "modifier"
},
{
"tagName": "@remarks",
"syntaxKind": "block"
},
{
"tagName": "@returns",
"syntaxKind": "block"
},
{
"tagName": "@sealed",
"syntaxKind": "modifier"
},
{
"tagName": "@see",
"syntaxKind": "block"
},
{
"tagName": "@throws",
"syntaxKind": "block",
"allowMultiple": true
},
{
"tagName": "@typeParam",
"syntaxKind": "block",
"allowMultiple": true
},
{
"tagName": "@virtual",
"syntaxKind": "modifier"
},
{
"tagName": "@betaDocumentation",
"syntaxKind": "modifier"
},
{
"tagName": "@internalRemarks",
"syntaxKind": "block"
},
{
"tagName": "@preapproved",
"syntaxKind": "modifier"
}
],
"supportForTags": {
"@alpha": true,
"@beta": true,
"@defaultValue": true,
"@decorator": true,
"@deprecated": true,
"@eventProperty": true,
"@example": true,
"@experimental": true,
"@inheritDoc": true,
"@internal": true,
"@label": true,
"@link": true,
"@override": true,
"@packageDocumentation": true,
"@param": true,
"@privateRemarks": true,
"@public": true,
"@readonly": true,
"@remarks": true,
"@returns": true,
"@sealed": true,
"@see": true,
"@throws": true,
"@typeParam": true,
"@virtual": true,
"@betaDocumentation": true,
"@internalRemarks": true,
"@preapproved": true
},
"reportUnsupportedHtmlElements": false
}
},
"kind": "Package",
"canonicalReference": "@tldraw/tlschema!",
"docComment": "",
"name": "@tldraw/tlschema",
"preserveMemberOrder": false,
"members": [
{
"kind": "EntryPoint",
"canonicalReference": "@tldraw/tlschema!",
"name": "",
"preserveMemberOrder": false,
"members": [
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!ArrowShapeArrowheadEndStyle:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "ArrowShapeArrowheadEndStyle: "
},
{
"kind": "Content",
"text": "import(\"../styles/StyleProp\")."
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "<\"arrow\" | \"bar\" | \"diamond\" | \"dot\" | \"inverted\" | \"none\" | \"pipe\" | \"square\" | \"triangle\">"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLArrowShape.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "ArrowShapeArrowheadEndStyle",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 4
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!ArrowShapeArrowheadStartStyle:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "ArrowShapeArrowheadStartStyle: "
},
{
"kind": "Content",
"text": "import(\"../styles/StyleProp\")."
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "<\"arrow\" | \"bar\" | \"diamond\" | \"dot\" | \"inverted\" | \"none\" | \"pipe\" | \"square\" | \"triangle\">"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLArrowShape.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "ArrowShapeArrowheadStartStyle",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 4
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!arrowShapeProps:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "arrowShapeProps: "
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "{\n arrowheadEnd: import(\"../styles/StyleProp\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"arrow\" | \"bar\" | \"diamond\" | \"dot\" | \"inverted\" | \"none\" | \"pipe\" | \"square\" | \"triangle\">;\n arrowheadStart: import(\"../styles/StyleProp\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"arrow\" | \"bar\" | \"diamond\" | \"dot\" | \"inverted\" | \"none\" | \"pipe\" | \"square\" | \"triangle\">;\n bend: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<number>;\n color: import(\"../styles/StyleProp\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"black\" | \"blue\" | \"green\" | \"grey\" | \"light-blue\" | \"light-green\" | \"light-red\" | \"light-violet\" | \"orange\" | \"red\" | \"violet\" | \"white\" | \"yellow\">;\n dash: import(\"../styles/StyleProp\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"dashed\" | \"dotted\" | \"draw\" | \"solid\">;\n end: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.UnionValidator",
"canonicalReference": "@tldraw/validate!UnionValidator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"type\", {\n binding: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.ObjectValidator",
"canonicalReference": "@tldraw/validate!ObjectValidator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<{\n boundShapeId: import(\"../records/TLShape\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "TLShapeId",
"canonicalReference": "@tldraw/tlschema!TLShapeId:type"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": ";\n isExact: boolean;\n isPrecise: boolean;\n normalizedAnchor: import(\"../misc/geometry-types\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "VecModel",
"canonicalReference": "@tldraw/tlschema!VecModel:interface"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": ";\n type: \"binding\";\n } & {}>;\n point: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.ObjectValidator",
"canonicalReference": "@tldraw/validate!ObjectValidator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<{\n type: \"point\";\n x: number;\n y: number;\n } & {}>;\n }, never>;\n fill: import(\"../styles/StyleProp\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"none\" | \"pattern\" | \"semi\" | \"solid\">;\n font: import(\"../styles/StyleProp\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"draw\" | \"mono\" | \"sans\" | \"serif\">;\n labelColor: import(\"../styles/StyleProp\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"black\" | \"blue\" | \"green\" | \"grey\" | \"light-blue\" | \"light-green\" | \"light-red\" | \"light-violet\" | \"orange\" | \"red\" | \"violet\" | \"white\" | \"yellow\">;\n labelPosition: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<number>;\n size: import(\"../styles/StyleProp\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"l\" | \"m\" | \"s\" | \"xl\">;\n start: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.UnionValidator",
"canonicalReference": "@tldraw/validate!UnionValidator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"type\", {\n binding: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.ObjectValidator",
"canonicalReference": "@tldraw/validate!ObjectValidator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<{\n boundShapeId: import(\"../records/TLShape\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "TLShapeId",
"canonicalReference": "@tldraw/tlschema!TLShapeId:type"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": ";\n isExact: boolean;\n isPrecise: boolean;\n normalizedAnchor: import(\"../misc/geometry-types\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "VecModel",
"canonicalReference": "@tldraw/tlschema!VecModel:interface"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": ";\n type: \"binding\";\n } & {}>;\n point: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.ObjectValidator",
"canonicalReference": "@tldraw/validate!ObjectValidator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<{\n type: \"point\";\n x: number;\n y: number;\n } & {}>;\n }, never>;\n text: "
arrows: add ability to change label placement (#2557) This adds the ability to drag the label on an arrow to a different location within the line segment/arc. https://github.com/tldraw/tldraw/assets/469604/dbd2ee35-bebc-48d6-b8ee-fcf12ce91fa5 - A lot of the complexity lay in ensuring a fixed distance from the ends of the arrowheads. - I added a new type of handle `text-adjust` that makes the text box the very handle itself. - I added a `ARROW_HANDLES` enum - we should use more enums! - The bulk of the changes are in ArrowShapeUtil — check that out in particular obviously :) Along the way, I tried to improve a couple spots as I touched them: - added some more documentation to Vec.ts because some of the functions in there were obscure/new to me. (at least the naming, hah) - added `getPointOnCircle` which was being done in a couple places independently and refactored those places. ### Questions - the `getPointOnCircle` API changed. Is this considered breaking and/or should I leave the signature the same? Wasn't sure if it was a big deal or not. - I made `labelPosition` in the schema always but I guess it could have been optional? Lemme know if there's a preference. - Any feedback on tests? Happy to expand those if necessary. ### 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 ### Test Plan 1. For arrow in [straightArrow, curvedArrow] test the following: a. Label in the middle b. Label at both ends of the arrow c. Test arrows in different directions d. Rotating the endpoints and seeing that the label stays at the end of the arrow at a fixed width. e. Test different stroke widths. f. Test with different arrowheads. 2. Also, test arcs that are more circle like than arc-like. - [x] Unit Tests - [ ] End to end tests ### Release Notes - Adds ability to change label position on arrows. --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com> Co-authored-by: alex <alex@dytry.ch>
2024-01-24 10:19:20 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<string>;\n}"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLArrowShape.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "arrowShapeProps",
"variableTypeTokenRange": {
"startIndex": 1,
arrows: add ability to change label placement (#2557) This adds the ability to drag the label on an arrow to a different location within the line segment/arc. https://github.com/tldraw/tldraw/assets/469604/dbd2ee35-bebc-48d6-b8ee-fcf12ce91fa5 - A lot of the complexity lay in ensuring a fixed distance from the ends of the arrowheads. - I added a new type of handle `text-adjust` that makes the text box the very handle itself. - I added a `ARROW_HANDLES` enum - we should use more enums! - The bulk of the changes are in ArrowShapeUtil — check that out in particular obviously :) Along the way, I tried to improve a couple spots as I touched them: - added some more documentation to Vec.ts because some of the functions in there were obscure/new to me. (at least the naming, hah) - added `getPointOnCircle` which was being done in a couple places independently and refactored those places. ### Questions - the `getPointOnCircle` API changed. Is this considered breaking and/or should I leave the signature the same? Wasn't sure if it was a big deal or not. - I made `labelPosition` in the schema always but I guess it could have been optional? Lemme know if there's a preference. - Any feedback on tests? Happy to expand those if necessary. ### 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 ### Test Plan 1. For arrow in [straightArrow, curvedArrow] test the following: a. Label in the middle b. Label at both ends of the arrow c. Test arrows in different directions d. Rotating the endpoints and seeing that the label stays at the end of the arrow at a fixed width. e. Test different stroke widths. f. Test with different arrowheads. 2. Also, test arcs that are more circle like than arc-like. - [x] Unit Tests - [ ] End to end tests ### Release Notes - Adds ability to change label position on arrows. --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com> Co-authored-by: alex <alex@dytry.ch>
2024-01-24 10:19:20 +00:00
"endIndex": 44
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!assetIdValidator:var",
"docComment": "/**\n * A validator for asset record type Ids.\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "assetIdValidator: "
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLAssetId",
"canonicalReference": "@tldraw/tlschema!TLAssetId:type"
},
{
"kind": "Content",
"text": ">"
}
],
"fileUrlPath": "packages/tlschema/src/assets/TLBaseAsset.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "assetIdValidator",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!AssetRecordType:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "AssetRecordType: "
},
{
"kind": "Content",
"text": "import(\"@tldraw/store\")."
},
{
"kind": "Reference",
"text": "RecordType",
"canonicalReference": "@tldraw/store!RecordType:class"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLAsset",
"canonicalReference": "@tldraw/tlschema!TLAsset:type"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": ", \"props\" | \"type\">"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/records/TLAsset.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "AssetRecordType",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 6
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!bookmarkShapeProps:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "bookmarkShapeProps: "
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "{\n assetId: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<import(\"..\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "TLAssetId",
"canonicalReference": "@tldraw/tlschema!TLAssetId:type"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": " | null>;\n h: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<number>;\n url: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<string>;\n w: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<number>;\n}"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLBookmarkShape.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "bookmarkShapeProps",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 12
}
},
{
"kind": "Interface",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"canonicalReference": "@tldraw/tlschema!BoxModel:interface",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"docComment": "/**\n * A serializable model for 2D boxes.\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"text": "export interface BoxModel "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/misc/geometry-types.ts",
"releaseTag": "Public",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"name": "BoxModel",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"preserveMemberOrder": false,
"members": [
{
"kind": "PropertySignature",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"canonicalReference": "@tldraw/tlschema!BoxModel#h:member",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "h: "
},
{
"kind": "Content",
"text": "number"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "h",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"canonicalReference": "@tldraw/tlschema!BoxModel#w:member",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "w: "
},
{
"kind": "Content",
"text": "number"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "w",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"canonicalReference": "@tldraw/tlschema!BoxModel#x:member",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "x: "
},
{
"kind": "Content",
"text": "number"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "x",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"canonicalReference": "@tldraw/tlschema!BoxModel#y:member",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "y: "
},
{
"kind": "Content",
"text": "number"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "y",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
}
],
"extendsTokenRanges": []
},
{
"kind": "Variable",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"canonicalReference": "@tldraw/tlschema!boxModelValidator:var",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"text": "boxModelValidator: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"text": "BoxModel",
"canonicalReference": "@tldraw/tlschema!BoxModel:interface"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ">"
}
],
"fileUrlPath": "packages/tlschema/src/misc/geometry-types.ts",
"isReadonly": true,
"releaseTag": "Public",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"name": "boxModelValidator",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!CameraRecordType:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "CameraRecordType: "
},
{
"kind": "Content",
"text": "import(\"@tldraw/store\")."
},
{
"kind": "Reference",
"text": "RecordType",
"canonicalReference": "@tldraw/store!RecordType:class"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLCamera",
"canonicalReference": "@tldraw/tlschema!TLCamera:interface"
},
{
"kind": "Content",
"text": ", never>"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLCamera.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "CameraRecordType",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 6
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!canvasUiColorTypeValidator:var",
"docComment": "/**\n * A validator for the colors used by tldraw's default shapes.\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "canvasUiColorTypeValidator: "
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "<\"accent\" | \"black\" | \"laser\" | \"muted-1\" | \"selection-fill\" | \"selection-stroke\" | \"white\">"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/misc/TLColor.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "canvasUiColorTypeValidator",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 3
}
},
{
"kind": "Function",
"canonicalReference": "@tldraw/tlschema!createAssetValidator:function(1)",
"docComment": "/**\n * Create a validator for an asset record type.\n *\n * @param type - The type of the asset\n *\n * @param props - The validator for the asset's props\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export declare function createAssetValidator<Type extends "
},
{
"kind": "Content",
"text": "string"
},
{
"kind": "Content",
"text": ", Props extends "
},
{
"kind": "Reference",
"text": "JsonObject",
"canonicalReference": "@tldraw/utils!JsonObject:type"
},
{
"kind": "Content",
"text": ">(type: "
},
{
"kind": "Content",
"text": "Type"
},
{
"kind": "Content",
"text": ", props: "
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
"text": "<Props>"
},
{
"kind": "Content",
"text": "): "
},
{
"kind": "Reference",
"text": "T.ObjectValidator",
"canonicalReference": "@tldraw/validate!ObjectValidator:class"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "<{ [P in \"id\" | \"meta\" | \"typeName\" | (undefined extends Props ? never : \"props\") | (undefined extends Type ? never : \"type\")]: {\n id: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "TLAssetId",
"canonicalReference": "@tldraw/tlschema!TLAssetId:type"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": ";\n meta: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "JsonObject",
"canonicalReference": "@tldraw/utils!JsonObject:type"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": ";\n props: Props;\n type: Type;\n typeName: 'asset';\n}[P]; } & { [P_1 in (undefined extends Props ? \"props\" : never) | (undefined extends Type ? \"type\" : never)]?: {\n id: "
Faster validations + record reference stability at the same time (#2848) This PR adds a validation mode whereby previous known-to-be-valid values can be used to speed up the validation process itself. At the same time it enables us to do fine-grained equality checking on records much more quickly than by using something like lodash isEqual, and using that we can prevent triggering effects for record updates that don't actually alter any values in the store. Here's some preliminary perf testing of average time spent in `store.put()` during some common interactions | task | before (ms) | after (ms) | | ---- | ---- | ---- | | drawing lines | 0.0403 | 0.0214 | | drawing boxes | 0.0408 | 0.0348 | | translating lines | 0.0352 | 0.0042 | | translating boxes | 0.0051 | 0.0032 | | rotating lines | 0.0312 | 0.0065 | | rotating boxes | 0.0053 | 0.0035 | | brush selecting boxes | 0.0200 | 0.0232 | | traversal with shapes | 0.0130 | 0.0108 | | traversal without shapes | 0.0201 | 0.0173 | **traversal** means moving the camera and pointer around the canvas #### Discussion At the scale of hundredths of a millisecond these .put operations are so fast that even if they became literally instantaneous the change would not be human perceptible. That said, there is an overall marked improvement here. Especially for dealing with draw shapes. These figures are also mostly in line with expectations, aside from a couple of things: - I don't understand why the `brush selecting boxes` task got slower after the change. - I don't understand why the `traversal` tasks are slower than the `translating boxes` task, both before and after. I would expect that .putting shape records would be much slower than .putting pointer/camera records (since the latter have fewer and simpler properties) ### Change Type - [x] `patch` — Bug fix ### 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.
2024-02-20 12:35:25 +00:00
},
{
"kind": "Reference",
"text": "TLAssetId",
"canonicalReference": "@tldraw/tlschema!TLAssetId:type"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": ";\n meta: "
Faster validations + record reference stability at the same time (#2848) This PR adds a validation mode whereby previous known-to-be-valid values can be used to speed up the validation process itself. At the same time it enables us to do fine-grained equality checking on records much more quickly than by using something like lodash isEqual, and using that we can prevent triggering effects for record updates that don't actually alter any values in the store. Here's some preliminary perf testing of average time spent in `store.put()` during some common interactions | task | before (ms) | after (ms) | | ---- | ---- | ---- | | drawing lines | 0.0403 | 0.0214 | | drawing boxes | 0.0408 | 0.0348 | | translating lines | 0.0352 | 0.0042 | | translating boxes | 0.0051 | 0.0032 | | rotating lines | 0.0312 | 0.0065 | | rotating boxes | 0.0053 | 0.0035 | | brush selecting boxes | 0.0200 | 0.0232 | | traversal with shapes | 0.0130 | 0.0108 | | traversal without shapes | 0.0201 | 0.0173 | **traversal** means moving the camera and pointer around the canvas #### Discussion At the scale of hundredths of a millisecond these .put operations are so fast that even if they became literally instantaneous the change would not be human perceptible. That said, there is an overall marked improvement here. Especially for dealing with draw shapes. These figures are also mostly in line with expectations, aside from a couple of things: - I don't understand why the `brush selecting boxes` task got slower after the change. - I don't understand why the `traversal` tasks are slower than the `translating boxes` task, both before and after. I would expect that .putting shape records would be much slower than .putting pointer/camera records (since the latter have fewer and simpler properties) ### Change Type - [x] `patch` — Bug fix ### 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.
2024-02-20 12:35:25 +00:00
},
{
"kind": "Reference",
"text": "JsonObject",
"canonicalReference": "@tldraw/utils!JsonObject:type"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": ";\n props: Props;\n type: Type;\n typeName: 'asset';\n}[P_1] | undefined; }>"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/assets/TLBaseAsset.ts",
"returnTypeTokenRange": {
"startIndex": 10,
Faster validations + record reference stability at the same time (#2848) This PR adds a validation mode whereby previous known-to-be-valid values can be used to speed up the validation process itself. At the same time it enables us to do fine-grained equality checking on records much more quickly than by using something like lodash isEqual, and using that we can prevent triggering effects for record updates that don't actually alter any values in the store. Here's some preliminary perf testing of average time spent in `store.put()` during some common interactions | task | before (ms) | after (ms) | | ---- | ---- | ---- | | drawing lines | 0.0403 | 0.0214 | | drawing boxes | 0.0408 | 0.0348 | | translating lines | 0.0352 | 0.0042 | | translating boxes | 0.0051 | 0.0032 | | rotating lines | 0.0312 | 0.0065 | | rotating boxes | 0.0053 | 0.0035 | | brush selecting boxes | 0.0200 | 0.0232 | | traversal with shapes | 0.0130 | 0.0108 | | traversal without shapes | 0.0201 | 0.0173 | **traversal** means moving the camera and pointer around the canvas #### Discussion At the scale of hundredths of a millisecond these .put operations are so fast that even if they became literally instantaneous the change would not be human perceptible. That said, there is an overall marked improvement here. Especially for dealing with draw shapes. These figures are also mostly in line with expectations, aside from a couple of things: - I don't understand why the `brush selecting boxes` task got slower after the change. - I don't understand why the `traversal` tasks are slower than the `translating boxes` task, both before and after. I would expect that .putting shape records would be much slower than .putting pointer/camera records (since the latter have fewer and simpler properties) ### Change Type - [x] `patch` — Bug fix ### 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.
2024-02-20 12:35:25 +00:00
"endIndex": 20
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
"releaseTag": "Public",
"overloadIndex": 1,
"parameters": [
{
"parameterName": "type",
"parameterTypeTokenRange": {
"startIndex": 5,
"endIndex": 6
},
"isOptional": false
},
{
"parameterName": "props",
"parameterTypeTokenRange": {
"startIndex": 7,
"endIndex": 9
},
"isOptional": false
}
],
"typeParameters": [
{
"typeParameterName": "Type",
"constraintTokenRange": {
"startIndex": 1,
"endIndex": 2
},
"defaultTypeTokenRange": {
"startIndex": 0,
"endIndex": 0
}
},
{
"typeParameterName": "Props",
"constraintTokenRange": {
"startIndex": 3,
"endIndex": 4
},
"defaultTypeTokenRange": {
"startIndex": 0,
"endIndex": 0
}
}
],
"name": "createAssetValidator"
},
{
bump typescript / api-extractor (#2949) This PR bumps TypeScript to 5.3.3 and API extractor. We started getting some weird behavior in CI due to different versions of the two libraries, ie where the CI api.jsons would differ from those built locally. ### Change Type - [x] `dependencies` — Changes to package dependencies[^1]
2024-02-25 11:43:17 +00:00
"kind": "Function",
"canonicalReference": "@tldraw/tlschema!createPresenceStateDerivation:function(1)",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"docComment": "/**\n * Creates a derivation that represents the current presence state of the current user.\n *\n * @public\n */\n",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"excerptTokens": [
{
"kind": "Content",
bump typescript / api-extractor (#2949) This PR bumps TypeScript to 5.3.3 and API extractor. We started getting some weird behavior in CI due to different versions of the two libraries, ie where the CI api.jsons would differ from those built locally. ### Change Type - [x] `dependencies` — Changes to package dependencies[^1]
2024-02-25 11:43:17 +00:00
"text": "createPresenceStateDerivation: ($user: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "Signal",
"canonicalReference": "@tldraw/state!Signal:interface"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<{\n color: string;\n id: string;\n name: string;\n}>"
bump typescript / api-extractor (#2949) This PR bumps TypeScript to 5.3.3 and API extractor. We started getting some weird behavior in CI due to different versions of the two libraries, ie where the CI api.jsons would differ from those built locally. ### Change Type - [x] `dependencies` — Changes to package dependencies[^1]
2024-02-25 11:43:17 +00:00
},
{
"kind": "Content",
"text": ", instanceId?: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "TLInstancePresence",
"canonicalReference": "@tldraw/tlschema!TLInstancePresence:interface"
},
{
"kind": "Content",
bump typescript / api-extractor (#2949) This PR bumps TypeScript to 5.3.3 and API extractor. We started getting some weird behavior in CI due to different versions of the two libraries, ie where the CI api.jsons would differ from those built locally. ### Change Type - [x] `dependencies` — Changes to package dependencies[^1]
2024-02-25 11:43:17 +00:00
"text": "['id']"
},
{
"kind": "Content",
"text": ") => "
},
{
"kind": "Content",
"text": "(store: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "TLStore",
"canonicalReference": "@tldraw/tlschema!TLStore:type"
},
{
"kind": "Content",
"text": ") => "
},
{
"kind": "Reference",
"text": "Signal",
"canonicalReference": "@tldraw/state!Signal:interface"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "<null | "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "TLInstancePresence",
"canonicalReference": "@tldraw/tlschema!TLInstancePresence:interface"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": ">"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/createPresenceStateDerivation.ts",
bump typescript / api-extractor (#2949) This PR bumps TypeScript to 5.3.3 and API extractor. We started getting some weird behavior in CI due to different versions of the two libraries, ie where the CI api.jsons would differ from those built locally. ### Change Type - [x] `dependencies` — Changes to package dependencies[^1]
2024-02-25 11:43:17 +00:00
"returnTypeTokenRange": {
"startIndex": 7,
"endIndex": 14
},
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"releaseTag": "Public",
bump typescript / api-extractor (#2949) This PR bumps TypeScript to 5.3.3 and API extractor. We started getting some weird behavior in CI due to different versions of the two libraries, ie where the CI api.jsons would differ from those built locally. ### Change Type - [x] `dependencies` — Changes to package dependencies[^1]
2024-02-25 11:43:17 +00:00
"overloadIndex": 1,
"parameters": [
{
"parameterName": "$user",
"parameterTypeTokenRange": {
"startIndex": 1,
"endIndex": 3
},
"isOptional": false
},
{
"parameterName": "instanceId",
"parameterTypeTokenRange": {
"startIndex": 4,
"endIndex": 6
},
"isOptional": true
}
],
"name": "createPresenceStateDerivation"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Function",
"canonicalReference": "@tldraw/tlschema!createShapeId:function(1)",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export declare function createShapeId(id?: "
},
{
"kind": "Content",
"text": "string"
},
{
"kind": "Content",
"text": "): "
},
{
"kind": "Reference",
"text": "TLShapeId",
"canonicalReference": "@tldraw/tlschema!TLShapeId:type"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLShape.ts",
"returnTypeTokenRange": {
"startIndex": 3,
"endIndex": 4
},
"releaseTag": "Public",
"overloadIndex": 1,
"parameters": [
{
"parameterName": "id",
"parameterTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
},
"isOptional": true
}
],
"name": "createShapeId"
},
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
{
"kind": "Function",
"canonicalReference": "@tldraw/tlschema!createShapePropsMigrationSequence:function(1)",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export declare function createShapePropsMigrationSequence(migrations: "
},
{
"kind": "Reference",
"text": "TLShapePropsMigrations",
"canonicalReference": "@tldraw/tlschema!TLShapePropsMigrations:type"
},
{
"kind": "Content",
"text": "): "
},
{
"kind": "Reference",
"text": "TLShapePropsMigrations",
"canonicalReference": "@tldraw/tlschema!TLShapePropsMigrations:type"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLShape.ts",
"returnTypeTokenRange": {
"startIndex": 3,
"endIndex": 4
},
"releaseTag": "Public",
"overloadIndex": 1,
"parameters": [
{
"parameterName": "migrations",
"parameterTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
},
"isOptional": false
}
],
"name": "createShapePropsMigrationSequence"
},
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
{
"kind": "Function",
"canonicalReference": "@tldraw/tlschema!createShapeValidator:function(1)",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export declare function createShapeValidator<Type extends "
},
{
"kind": "Content",
"text": "string"
},
{
"kind": "Content",
"text": ", Props extends "
},
{
"kind": "Reference",
"text": "JsonObject",
"canonicalReference": "@tldraw/utils!JsonObject:type"
},
{
"kind": "Content",
"text": ", Meta extends "
},
{
"kind": "Reference",
"text": "JsonObject",
"canonicalReference": "@tldraw/utils!JsonObject:type"
},
{
"kind": "Content",
"text": ">(type: "
},
{
"kind": "Content",
"text": "Type"
},
{
"kind": "Content",
"text": ", props?: "
},
{
"kind": "Content",
"text": "{\n [K in keyof Props]: "
},
{
"kind": "Reference",
"text": "T.Validatable",
"canonicalReference": "@tldraw/validate!Validatable:type"
},
{
"kind": "Content",
"text": "<Props[K]>;\n}"
},
{
"kind": "Content",
"text": ", meta?: "
},
{
"kind": "Content",
"text": "{\n [K in keyof Meta]: "
},
{
"kind": "Reference",
"text": "T.Validatable",
"canonicalReference": "@tldraw/validate!Validatable:type"
},
{
"kind": "Content",
"text": "<Meta[K]>;\n}"
},
{
"kind": "Content",
"text": "): "
},
{
"kind": "Reference",
"text": "T.ObjectValidator",
"canonicalReference": "@tldraw/validate!ObjectValidator:class"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "<{ [P in \"id\" | \"index\" | \"isLocked\" | \"meta\" | \"opacity\" | \"parentId\" | \"rotation\" | \"typeName\" | \"x\" | \"y\" | (undefined extends Props ? never : \"props\") | (undefined extends Type ? never : \"type\")]: "
Faster validations + record reference stability at the same time (#2848) This PR adds a validation mode whereby previous known-to-be-valid values can be used to speed up the validation process itself. At the same time it enables us to do fine-grained equality checking on records much more quickly than by using something like lodash isEqual, and using that we can prevent triggering effects for record updates that don't actually alter any values in the store. Here's some preliminary perf testing of average time spent in `store.put()` during some common interactions | task | before (ms) | after (ms) | | ---- | ---- | ---- | | drawing lines | 0.0403 | 0.0214 | | drawing boxes | 0.0408 | 0.0348 | | translating lines | 0.0352 | 0.0042 | | translating boxes | 0.0051 | 0.0032 | | rotating lines | 0.0312 | 0.0065 | | rotating boxes | 0.0053 | 0.0035 | | brush selecting boxes | 0.0200 | 0.0232 | | traversal with shapes | 0.0130 | 0.0108 | | traversal without shapes | 0.0201 | 0.0173 | **traversal** means moving the camera and pointer around the canvas #### Discussion At the scale of hundredths of a millisecond these .put operations are so fast that even if they became literally instantaneous the change would not be human perceptible. That said, there is an overall marked improvement here. Especially for dealing with draw shapes. These figures are also mostly in line with expectations, aside from a couple of things: - I don't understand why the `brush selecting boxes` task got slower after the change. - I don't understand why the `traversal` tasks are slower than the `translating boxes` task, both before and after. I would expect that .putting shape records would be much slower than .putting pointer/camera records (since the latter have fewer and simpler properties) ### Change Type - [x] `patch` — Bug fix ### 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.
2024-02-20 12:35:25 +00:00
},
{
"kind": "Reference",
"text": "TLBaseShape",
"canonicalReference": "@tldraw/tlschema!TLBaseShape:interface"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "<Type, Props>[P]; } & { [P_1 in (undefined extends Props ? \"props\" : never) | (undefined extends Type ? \"type\" : never)]?: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "TLBaseShape",
"canonicalReference": "@tldraw/tlschema!TLBaseShape:interface"
},
{
"kind": "Content",
Faster validations + record reference stability at the same time (#2848) This PR adds a validation mode whereby previous known-to-be-valid values can be used to speed up the validation process itself. At the same time it enables us to do fine-grained equality checking on records much more quickly than by using something like lodash isEqual, and using that we can prevent triggering effects for record updates that don't actually alter any values in the store. Here's some preliminary perf testing of average time spent in `store.put()` during some common interactions | task | before (ms) | after (ms) | | ---- | ---- | ---- | | drawing lines | 0.0403 | 0.0214 | | drawing boxes | 0.0408 | 0.0348 | | translating lines | 0.0352 | 0.0042 | | translating boxes | 0.0051 | 0.0032 | | rotating lines | 0.0312 | 0.0065 | | rotating boxes | 0.0053 | 0.0035 | | brush selecting boxes | 0.0200 | 0.0232 | | traversal with shapes | 0.0130 | 0.0108 | | traversal without shapes | 0.0201 | 0.0173 | **traversal** means moving the camera and pointer around the canvas #### Discussion At the scale of hundredths of a millisecond these .put operations are so fast that even if they became literally instantaneous the change would not be human perceptible. That said, there is an overall marked improvement here. Especially for dealing with draw shapes. These figures are also mostly in line with expectations, aside from a couple of things: - I don't understand why the `brush selecting boxes` task got slower after the change. - I don't understand why the `traversal` tasks are slower than the `translating boxes` task, both before and after. I would expect that .putting shape records would be much slower than .putting pointer/camera records (since the latter have fewer and simpler properties) ### Change Type - [x] `patch` — Bug fix ### 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.
2024-02-20 12:35:25 +00:00
"text": "<Type, Props>[P_1] | undefined; }>"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLBaseShape.ts",
"returnTypeTokenRange": {
"startIndex": 17,
Faster validations + record reference stability at the same time (#2848) This PR adds a validation mode whereby previous known-to-be-valid values can be used to speed up the validation process itself. At the same time it enables us to do fine-grained equality checking on records much more quickly than by using something like lodash isEqual, and using that we can prevent triggering effects for record updates that don't actually alter any values in the store. Here's some preliminary perf testing of average time spent in `store.put()` during some common interactions | task | before (ms) | after (ms) | | ---- | ---- | ---- | | drawing lines | 0.0403 | 0.0214 | | drawing boxes | 0.0408 | 0.0348 | | translating lines | 0.0352 | 0.0042 | | translating boxes | 0.0051 | 0.0032 | | rotating lines | 0.0312 | 0.0065 | | rotating boxes | 0.0053 | 0.0035 | | brush selecting boxes | 0.0200 | 0.0232 | | traversal with shapes | 0.0130 | 0.0108 | | traversal without shapes | 0.0201 | 0.0173 | **traversal** means moving the camera and pointer around the canvas #### Discussion At the scale of hundredths of a millisecond these .put operations are so fast that even if they became literally instantaneous the change would not be human perceptible. That said, there is an overall marked improvement here. Especially for dealing with draw shapes. These figures are also mostly in line with expectations, aside from a couple of things: - I don't understand why the `brush selecting boxes` task got slower after the change. - I don't understand why the `traversal` tasks are slower than the `translating boxes` task, both before and after. I would expect that .putting shape records would be much slower than .putting pointer/camera records (since the latter have fewer and simpler properties) ### Change Type - [x] `patch` — Bug fix ### 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.
2024-02-20 12:35:25 +00:00
"endIndex": 23
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
"releaseTag": "Public",
"overloadIndex": 1,
"parameters": [
{
"parameterName": "type",
"parameterTypeTokenRange": {
"startIndex": 7,
"endIndex": 8
},
"isOptional": false
},
{
"parameterName": "props",
"parameterTypeTokenRange": {
"startIndex": 9,
"endIndex": 12
},
"isOptional": true
},
{
"parameterName": "meta",
"parameterTypeTokenRange": {
"startIndex": 13,
"endIndex": 16
},
"isOptional": true
}
],
"typeParameters": [
{
"typeParameterName": "Type",
"constraintTokenRange": {
"startIndex": 1,
"endIndex": 2
},
"defaultTypeTokenRange": {
"startIndex": 0,
"endIndex": 0
}
},
{
"typeParameterName": "Props",
"constraintTokenRange": {
"startIndex": 3,
"endIndex": 4
},
"defaultTypeTokenRange": {
"startIndex": 0,
"endIndex": 0
}
},
{
"typeParameterName": "Meta",
"constraintTokenRange": {
"startIndex": 5,
"endIndex": 6
},
"defaultTypeTokenRange": {
"startIndex": 0,
"endIndex": 0
}
}
],
"name": "createShapeValidator"
},
{
"kind": "Function",
"canonicalReference": "@tldraw/tlschema!createTLSchema:function(1)",
"docComment": "/**\n * Create a TLSchema with custom shapes. Custom shapes cannot override default shapes.\n *\n * @param opts - Options\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "export declare function createTLSchema({ shapes, migrations, }?: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "{\n migrations?: readonly "
},
{
"kind": "Reference",
"text": "MigrationSequence",
"canonicalReference": "@tldraw/store!MigrationSequence:interface"
},
{
"kind": "Content",
"text": "[];\n shapes?: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "Record",
"canonicalReference": "!Record:type"
},
{
"kind": "Content",
"text": "<string, "
},
{
"kind": "Reference",
"text": "SchemaShapeInfo",
"canonicalReference": "@tldraw/tlschema!SchemaShapeInfo:type"
},
{
"kind": "Content",
"text": ">;\n}"
},
{
"kind": "Content",
"text": "): "
},
{
"kind": "Reference",
"text": "TLSchema",
"canonicalReference": "@tldraw/tlschema!TLSchema:type"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/createTLSchema.ts",
"returnTypeTokenRange": {
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"startIndex": 9,
"endIndex": 10
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
"releaseTag": "Public",
"overloadIndex": 1,
"parameters": [
{
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"parameterName": "{ shapes, migrations, }",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"parameterTypeTokenRange": {
"startIndex": 1,
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"endIndex": 8
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
Setup papercuts (#2987) I'm bringing the sockets example up to date and ran into some issues that were tricky to resolve in userland but trivial to resolve in packageland. Gonna collect them here. ### 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.
2024-02-29 10:40:28 +00:00
"isOptional": true
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"name": "createTLSchema"
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!DefaultColorStyle:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "DefaultColorStyle: "
},
{
"kind": "Content",
"text": "import(\"./StyleProp\")."
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
Add white (#3321) This PR adds white. It's available with Alt+T. ![Kapture 2024-04-01 at 18 32 22](https://github.com/tldraw/tldraw/assets/23072548/932c9621-ee09-403f-aacc-0226e7b03967) ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `feature` — New feature ### Release Notes - Adds secret white color.
2024-04-01 18:48:56 +00:00
"text": "<\"black\" | \"blue\" | \"green\" | \"grey\" | \"light-blue\" | \"light-green\" | \"light-red\" | \"light-violet\" | \"orange\" | \"red\" | \"violet\" | \"white\" | \"yellow\">"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/styles/TLColorStyle.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "DefaultColorStyle",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 4
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!DefaultColorThemePalette:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "DefaultColorThemePalette: "
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "{\n darkMode: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "TLDefaultColorTheme",
"canonicalReference": "@tldraw/tlschema!TLDefaultColorTheme:type"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": ";\n lightMode: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "TLDefaultColorTheme",
"canonicalReference": "@tldraw/tlschema!TLDefaultColorTheme:type"
},
{
"kind": "Content",
"text": ";\n}"
}
],
"fileUrlPath": "packages/tlschema/src/styles/TLColorStyle.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "DefaultColorThemePalette",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 6
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!DefaultDashStyle:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "DefaultDashStyle: "
},
{
"kind": "Content",
"text": "import(\"./StyleProp\")."
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "<\"dashed\" | \"dotted\" | \"draw\" | \"solid\">"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/styles/TLDashStyle.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "DefaultDashStyle",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 4
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!DefaultFillStyle:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "DefaultFillStyle: "
},
{
"kind": "Content",
"text": "import(\"./StyleProp\")."
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "<\"none\" | \"pattern\" | \"semi\" | \"solid\">"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/styles/TLFillStyle.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "DefaultFillStyle",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 4
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!DefaultFontFamilies:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "DefaultFontFamilies: "
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "{\n draw: string;\n mono: string;\n sans: string;\n serif: string;\n}"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/styles/TLFontStyle.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "DefaultFontFamilies",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!DefaultFontStyle:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "DefaultFontStyle: "
},
{
"kind": "Content",
"text": "import(\"./StyleProp\")."
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "<\"draw\" | \"mono\" | \"sans\" | \"serif\">"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/styles/TLFontStyle.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "DefaultFontStyle",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 4
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!DefaultHorizontalAlignStyle:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "DefaultHorizontalAlignStyle: "
},
{
"kind": "Content",
"text": "import(\"./StyleProp\")."
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "<\"end-legacy\" | \"end\" | \"middle-legacy\" | \"middle\" | \"start-legacy\" | \"start\">"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/styles/TLHorizontalAlignStyle.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "DefaultHorizontalAlignStyle",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 4
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!DefaultSizeStyle:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "DefaultSizeStyle: "
},
{
"kind": "Content",
"text": "import(\"./StyleProp\")."
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "<\"l\" | \"m\" | \"s\" | \"xl\">"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/styles/TLSizeStyle.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "DefaultSizeStyle",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 4
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!DefaultVerticalAlignStyle:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "DefaultVerticalAlignStyle: "
},
{
"kind": "Content",
"text": "import(\"./StyleProp\")."
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "<\"end\" | \"middle\" | \"start\">"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/styles/TLVerticalAlignStyle.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "DefaultVerticalAlignStyle",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 4
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!DocumentRecordType:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "DocumentRecordType: "
},
{
"kind": "Content",
"text": "import(\"@tldraw/store\")."
},
{
"kind": "Reference",
"text": "RecordType",
"canonicalReference": "@tldraw/store!RecordType:class"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLDocument",
"canonicalReference": "@tldraw/tlschema!TLDocument:interface"
},
{
"kind": "Content",
"text": ", never>"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLDocument.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "DocumentRecordType",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 6
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!drawShapeProps:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "drawShapeProps: "
},
{
"kind": "Content",
"text": "{\n color: import(\"..\")."
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"black\" | \"blue\" | \"green\" | \"grey\" | \"light-blue\" | \"light-green\" | \"light-red\" | \"light-violet\" | \"orange\" | \"red\" | \"violet\" | \"white\" | \"yellow\">;\n dash: import(\"..\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"dashed\" | \"dotted\" | \"draw\" | \"solid\">;\n fill: import(\"..\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"none\" | \"pattern\" | \"semi\" | \"solid\">;\n isClosed: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<boolean>;\n isComplete: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<boolean>;\n isPen: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<boolean>;\n segments: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.ArrayOfValidator",
"canonicalReference": "@tldraw/validate!ArrayOfValidator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<{\n points: import(\"../misc/geometry-types\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "VecModel",
"canonicalReference": "@tldraw/tlschema!VecModel:interface"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "[];\n type: \"free\" | \"straight\";\n } & {}>;\n size: import(\"..\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"l\" | \"m\" | \"s\" | \"xl\">;\n}"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLDrawShape.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "drawShapeProps",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 20
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!EMBED_DEFINITIONS:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "EMBED_DEFINITIONS: "
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "readonly [{\n readonly doesResize: true;\n readonly fromEmbedUrl: (url: string) => string | undefined;\n readonly height: 500;\n readonly hostnames: readonly [\"beta.tldraw.com\", \"tldraw.com\", \"localhost:3000\"];\n readonly minHeight: 300;\n readonly minWidth: 300;\n readonly overridePermissions: {\n readonly 'allow-top-navigation': true;\n };\n readonly title: \"tldraw\";\n readonly toEmbedUrl: (url: string) => string | undefined;\n readonly type: \"tldraw\";\n readonly width: 720;\n}, {\n readonly doesResize: true;\n readonly fromEmbedUrl: (url: string) => string | undefined;\n readonly height: 500;\n readonly hostnames: readonly [\"figma.com\"];\n readonly title: \"Figma\";\n readonly toEmbedUrl: (url: string) => string | undefined;\n readonly type: \"figma\";\n readonly width: 720;\n}, {\n readonly doesResize: true;\n readonly fromEmbedUrl: (url: string) => string | undefined;\n readonly height: 500;\n readonly hostnames: readonly [\"google.*\"];\n readonly title: \"Google Maps\";\n readonly toEmbedUrl: (url: string) => string | undefined;\n readonly type: \"google_maps\";\n readonly width: 720;\n}, {\n readonly doesResize: true;\n readonly fromEmbedUrl: (url: string) => string | undefined;\n readonly height: 500;\n readonly hostnames: readonly [\"val.town\"];\n readonly minHeight: 100;\n readonly minWidth: 260;\n readonly title: \"Val Town\";\n readonly toEmbedUrl: (url: string) => string | undefined;\n readonly type: \"val_town\";\n readonly width: 720;\n}, {\n readonly doesResize: true;\n readonly fromEmbedUrl: (url: string) => string | undefined;\n readonly height: 500;\n readonly hostnames: readonly [\"codesandbox.io\"];\n readonly minHeight: 300;\n readonly minWidth: 300;\n readonly title: \"CodeSandbox\";\n readonly toEmbedUrl: (url: string) => string | undefined;\n readonly type: \"codesandbox\";\n readonly width: 720;\n}, {\n readonly doesResize: true;\n readonly fromEmbedUrl: (url: string) => string | undefined;\n readonly height: 400;\n readonly hostnames: readonly [\"codepen.io\"];\n readonly minHeight: 300;\n readonly minWidth: 300;\n readonly title: \"Codepen\";\n readonly toEmbedUrl: (url: string) => string | undefined;\n readonly type: \"codepen\";\n readonly width: 520;\n}, {\n readonly doesResize: false;\n readonly fromEmbedUrl: (url: string) => string | undefined;\n readonly height: 400;\n readonly hostnames: readonly [\"scratch.mit.edu\"];\n readonly title: \"Scratch\";\n readonly toEmbedUrl: (url: string) => string | undefined;\n readonly type: \"scratch\";\n readonly width: 520;\n}, {\n readonly doesResize: true;\n readonly fromEmbedUrl: (url: string) => string | undefined;\n readonly height: 450;\n readonly hostnames: readonly [\"*.youtube.com\", \"youtube.com\", \"youtu.be\"];\n readonly isAspectRatioLocked: true;\n readonly overridePermissions: {\n readonly 'allow-presentation': true;\n };\n readonly title: \"YouTube\";\n readonly toEmbedUrl: (url: string) => string | undefined;\n readonly type: \"youtube\";\n readonly width: 800;\n}, {\n readonly doesResize: true;\n readonly fromEmbedUrl: (url: string) => string | undefined;\n readonly height: 500;\n readonly hostnames: readonly [\"calendar.google.*\"];\n readonly instructionLink: \"https://support.google.com/calendar/answer/41207?hl=en\";\n readonly minHeight: 360;\n readonly minWidth: 460;\n readonly title: \"Google Calendar\";\n readonly toEmbedUrl: (url: string) => string | undefined;\n readonly type: \"google_calendar\";\n readonly width: 720;\n}, {\n readonly doesResize: true;\n readonly fromEmbedUrl: (url: string) => string | undefined;\n readonly height: 500;\n readonly hostnames: readonly [\"docs.google.*\"];\n readonly minHeight: 360;\n readonly minWidth: 460;\n readonly title: \"Google Slides\";\n readonly
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLEmbedShape.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "EMBED_DEFINITIONS",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!EmbedDefinition:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type EmbedDefinition = "
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "{\n readonly backgroundColor?: string;\n readonly doesResize: boolean;\n readonly fromEmbedUrl: (url: string) => string | undefined;\n readonly height: number;\n readonly hostnames: readonly string[];\n readonly instructionLink?: string;\n readonly isAspectRatioLocked?: boolean;\n readonly minHeight?: number;\n readonly minWidth?: number;\n readonly overrideOutlineRadius?: number;\n readonly overridePermissions?: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "TLEmbedShapePermissions",
"canonicalReference": "@tldraw/tlschema!TLEmbedShapePermissions:type"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": ";\n readonly title: string;\n readonly toEmbedUrl: (url: string) => string | undefined;\n readonly type: string;\n readonly width: number;\n}"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLEmbedShape.ts",
"releaseTag": "Public",
"name": "EmbedDefinition",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 4
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!embedShapePermissionDefaults:var",
"docComment": "/**\n * Permissions with note inline from https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "embedShapePermissionDefaults: "
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "{\n readonly 'allow-downloads-without-user-activation': false;\n readonly 'allow-downloads': false;\n readonly 'allow-forms': true;\n readonly 'allow-modals': false;\n readonly 'allow-orientation-lock': false;\n readonly 'allow-pointer-lock': false;\n readonly 'allow-popups-to-escape-sandbox': false;\n readonly 'allow-popups': true;\n readonly 'allow-presentation': false;\n readonly 'allow-same-origin': true;\n readonly 'allow-scripts': true;\n readonly 'allow-storage-access-by-user-activation': false;\n readonly 'allow-top-navigation-by-user-activation': false;\n readonly 'allow-top-navigation': false;\n}"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLEmbedShape.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "embedShapePermissionDefaults",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!embedShapeProps:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "embedShapeProps: "
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "{\n h: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<number>;\n url: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<string>;\n w: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<number>;\n}"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLEmbedShape.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "embedShapeProps",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 8
}
},
{
"kind": "Class",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class",
"docComment": "/**\n * See {@link StyleProp} & {@link StyleProp.defineEnum}\n *\n * @remarks\n *\n * The constructor for this class is marked as internal. Third-party code should not call the constructor directly or create subclasses that extend the `EnumStyleProp` class.\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export declare class EnumStyleProp<T> extends "
},
{
"kind": "Reference",
"text": "StyleProp",
"canonicalReference": "@tldraw/tlschema!StyleProp:class"
},
{
"kind": "Content",
"text": "<T>"
},
{
"kind": "Content",
"text": " "
}
],
"fileUrlPath": "packages/tlschema/src/styles/StyleProp.ts",
"releaseTag": "Public",
"typeParameters": [
{
"typeParameterName": "T",
"constraintTokenRange": {
"startIndex": 0,
"endIndex": 0
},
"defaultTypeTokenRange": {
"startIndex": 0,
"endIndex": 0
}
}
],
"isAbstract": false,
"name": "EnumStyleProp",
"preserveMemberOrder": false,
"members": [
{
"kind": "Property",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp#values:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "readonly values: "
},
{
"kind": "Content",
"text": "readonly T[]"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": true,
"isOptional": false,
"releaseTag": "Public",
"name": "values",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
},
"isStatic": false,
"isProtected": false,
"isAbstract": false
}
],
"extendsTokenRange": {
"startIndex": 1,
"endIndex": 3
},
"implementsTokenRanges": []
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!frameShapeProps:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "frameShapeProps: "
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "{\n h: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<number>;\n name: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<string>;\n w: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<number>;\n}"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLFrameShape.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "frameShapeProps",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 8
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!GeoShapeGeoStyle:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "GeoShapeGeoStyle: "
},
{
"kind": "Content",
"text": "import(\"../styles/StyleProp\")."
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "<\"arrow-down\" | \"arrow-left\" | \"arrow-right\" | \"arrow-up\" | \"check-box\" | \"cloud\" | \"diamond\" | \"ellipse\" | \"hexagon\" | \"octagon\" | \"oval\" | \"pentagon\" | \"rectangle\" | \"rhombus-2\" | \"rhombus\" | \"star\" | \"trapezoid\" | \"triangle\" | \"x-box\">"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLGeoShape.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "GeoShapeGeoStyle",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 4
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!geoShapeProps:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "geoShapeProps: "
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "{\n align: import(\"../styles/StyleProp\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"end-legacy\" | \"end\" | \"middle-legacy\" | \"middle\" | \"start-legacy\" | \"start\">;\n color: import(\"../styles/StyleProp\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"black\" | \"blue\" | \"green\" | \"grey\" | \"light-blue\" | \"light-green\" | \"light-red\" | \"light-violet\" | \"orange\" | \"red\" | \"violet\" | \"white\" | \"yellow\">;\n dash: import(\"../styles/StyleProp\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"dashed\" | \"dotted\" | \"draw\" | \"solid\">;\n fill: import(\"../styles/StyleProp\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"none\" | \"pattern\" | \"semi\" | \"solid\">;\n font: import(\"../styles/StyleProp\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"draw\" | \"mono\" | \"sans\" | \"serif\">;\n geo: import(\"../styles/StyleProp\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"arrow-down\" | \"arrow-left\" | \"arrow-right\" | \"arrow-up\" | \"check-box\" | \"cloud\" | \"diamond\" | \"ellipse\" | \"hexagon\" | \"octagon\" | \"oval\" | \"pentagon\" | \"rectangle\" | \"rhombus-2\" | \"rhombus\" | \"star\" | \"trapezoid\" | \"triangle\" | \"x-box\">;\n growY: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<number>;\n h: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<number>;\n labelColor: import(\"../styles/StyleProp\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"black\" | \"blue\" | \"green\" | \"grey\" | \"light-blue\" | \"light-green\" | \"light-red\" | \"light-violet\" | \"orange\" | \"red\" | \"violet\" | \"white\" | \"yellow\">;\n size: import(\"../styles/StyleProp\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"l\" | \"m\" | \"s\" | \"xl\">;\n text: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<string>;\n url: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<string>;\n verticalAlign: import(\"../styles/StyleProp\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"end\" | \"middle\" | \"start\">;\n w: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<number>;\n}"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLGeoShape.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "geoShapeProps",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 30
}
},
{
"kind": "Function",
"canonicalReference": "@tldraw/tlschema!getDefaultColorTheme:function(1)",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export declare function getDefaultColorTheme(opts: "
},
{
"kind": "Content",
"text": "{\n isDarkMode: boolean;\n}"
},
{
"kind": "Content",
"text": "): "
},
{
"kind": "Reference",
"text": "TLDefaultColorTheme",
"canonicalReference": "@tldraw/tlschema!TLDefaultColorTheme:type"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/styles/TLColorStyle.ts",
"returnTypeTokenRange": {
"startIndex": 3,
"endIndex": 4
},
"releaseTag": "Public",
"overloadIndex": 1,
"parameters": [
{
"parameterName": "opts",
"parameterTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
},
"isOptional": false
}
],
"name": "getDefaultColorTheme"
},
{
"kind": "Function",
"canonicalReference": "@tldraw/tlschema!getDefaultTranslationLocale:function(1)",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export declare function getDefaultTranslationLocale(): "
},
{
"kind": "Reference",
"text": "TLLanguage",
"canonicalReference": "@tldraw/tlschema!TLLanguage:type"
},
{
"kind": "Content",
"text": "['locale']"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/translations/translations.ts",
"returnTypeTokenRange": {
"startIndex": 1,
"endIndex": 3
},
"releaseTag": "Public",
"overloadIndex": 1,
"parameters": [],
"name": "getDefaultTranslationLocale"
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!highlightShapeProps:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "highlightShapeProps: "
},
{
"kind": "Content",
"text": "{\n color: import(\"..\")."
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"black\" | \"blue\" | \"green\" | \"grey\" | \"light-blue\" | \"light-green\" | \"light-red\" | \"light-violet\" | \"orange\" | \"red\" | \"violet\" | \"white\" | \"yellow\">;\n isComplete: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<boolean>;\n isPen: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<boolean>;\n segments: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.ArrayOfValidator",
"canonicalReference": "@tldraw/validate!ArrayOfValidator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<{\n points: import(\"..\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "VecModel",
"canonicalReference": "@tldraw/tlschema!VecModel:interface"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "[];\n type: \"free\" | \"straight\";\n } & {}>;\n size: import(\"..\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"l\" | \"m\" | \"s\" | \"xl\">;\n}"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLHighlightShape.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "highlightShapeProps",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 14
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!imageShapeProps:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "imageShapeProps: "
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "{\n assetId: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<import(\"..\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "TLAssetId",
"canonicalReference": "@tldraw/tlschema!TLAssetId:type"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": " | null>;\n crop: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<({\n bottomRight: import(\"../misc/geometry-types\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "VecModel",
"canonicalReference": "@tldraw/tlschema!VecModel:interface"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": ";\n topLeft: import(\"../misc/geometry-types\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "VecModel",
"canonicalReference": "@tldraw/tlschema!VecModel:interface"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": ";\n } & {}) | null>;\n h: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<number>;\n playing: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<boolean>;\n url: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<string>;\n w: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<number>;\n}"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLImageShape.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "imageShapeProps",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 20
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!InstancePageStateRecordType:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "InstancePageStateRecordType: "
},
{
"kind": "Content",
"text": "import(\"@tldraw/store\")."
},
{
"kind": "Reference",
"text": "RecordType",
"canonicalReference": "@tldraw/store!RecordType:class"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLInstancePageState",
"canonicalReference": "@tldraw/tlschema!TLInstancePageState:interface"
},
{
"kind": "Content",
"text": ", \"pageId\">"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLPageState.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "InstancePageStateRecordType",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 6
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!InstancePresenceRecordType:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "InstancePresenceRecordType: "
},
{
"kind": "Content",
"text": "import(\"@tldraw/store\")."
},
{
"kind": "Reference",
"text": "RecordType",
"canonicalReference": "@tldraw/store!RecordType:class"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLInstancePresence",
"canonicalReference": "@tldraw/tlschema!TLInstancePresence:interface"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": ", \"currentPageId\" | \"userId\" | \"userName\">"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/records/TLPresence.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "InstancePresenceRecordType",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 6
}
},
{
"kind": "Function",
"canonicalReference": "@tldraw/tlschema!isPageId:function(1)",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export declare function isPageId(id: "
},
{
"kind": "Content",
"text": "string"
},
{
"kind": "Content",
"text": "): "
},
{
"kind": "Reference",
"text": "id",
"canonicalReference": "@tldraw/tlschema!~id"
},
{
"kind": "Content",
"text": " is "
},
{
"kind": "Reference",
"text": "TLPageId",
"canonicalReference": "@tldraw/tlschema!TLPageId:type"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLPage.ts",
"returnTypeTokenRange": {
"startIndex": 3,
"endIndex": 6
},
"releaseTag": "Public",
"overloadIndex": 1,
"parameters": [
{
"parameterName": "id",
"parameterTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
},
"isOptional": false
}
],
"name": "isPageId"
},
{
"kind": "Function",
"canonicalReference": "@tldraw/tlschema!isShape:function(1)",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export declare function isShape(record?: "
},
{
"kind": "Reference",
"text": "UnknownRecord",
"canonicalReference": "@tldraw/store!UnknownRecord:type"
},
{
"kind": "Content",
"text": "): "
},
{
"kind": "Reference",
"text": "record",
"canonicalReference": "@tldraw/tlschema!~record"
},
{
"kind": "Content",
"text": " is "
},
{
"kind": "Reference",
"text": "TLShape",
"canonicalReference": "@tldraw/tlschema!TLShape:type"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLShape.ts",
"returnTypeTokenRange": {
"startIndex": 3,
"endIndex": 6
},
"releaseTag": "Public",
"overloadIndex": 1,
"parameters": [
{
"parameterName": "record",
"parameterTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
},
"isOptional": true
}
],
"name": "isShape"
},
{
"kind": "Function",
"canonicalReference": "@tldraw/tlschema!isShapeId:function(1)",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export declare function isShapeId(id?: "
},
{
"kind": "Content",
"text": "string"
},
{
"kind": "Content",
"text": "): "
},
{
"kind": "Reference",
"text": "id",
"canonicalReference": "@tldraw/tlschema!~id"
},
{
"kind": "Content",
"text": " is "
},
{
"kind": "Reference",
"text": "TLShapeId",
"canonicalReference": "@tldraw/tlschema!TLShapeId:type"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLShape.ts",
"returnTypeTokenRange": {
"startIndex": 3,
"endIndex": 6
},
"releaseTag": "Public",
"overloadIndex": 1,
"parameters": [
{
"parameterName": "id",
"parameterTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
},
"isOptional": true
}
],
"name": "isShapeId"
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!LANGUAGES:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "LANGUAGES: "
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "readonly [{\n readonly label: \"Català\";\n readonly locale: \"ca\";\n}, {\n readonly label: \"Čeština\";\n readonly locale: \"cs\";\n}, {\n readonly label: \"Danish\";\n readonly locale: \"da\";\n}, {\n readonly label: \"Deutsch\";\n readonly locale: \"de\";\n}, {\n readonly label: \"English\";\n readonly locale: \"en\";\n}, {\n readonly label: \"Español\";\n readonly locale: \"es\";\n}, {\n readonly label: \"Français\";\n readonly locale: \"fr\";\n}, {\n readonly label: \"Galego\";\n readonly locale: \"gl\";\n}, {\n readonly label: \"Hrvatski\";\n readonly locale: \"hr\";\n}, {\n readonly label: \"Italiano\";\n readonly locale: \"it\";\n}, {\n readonly label: \"Magyar\";\n readonly locale: \"hu\";\n}, {\n readonly label: \"Norwegian\";\n readonly locale: \"no\";\n}, {\n readonly label: \"Polski\";\n readonly locale: \"pl\";\n}, {\n readonly label: \"Português - Brasil\";\n readonly locale: \"pt-br\";\n}, {\n readonly label: \"Português - Europeu\";\n readonly locale: \"pt-pt\";\n}, {\n readonly label: \"Română\";\n readonly locale: \"ro\";\n}, {\n readonly label: \"Russian\";\n readonly locale: \"ru\";\n}, {\n readonly label: \"Slovenščina\";\n readonly locale: \"sl\";\n}, {\n readonly label: \"Suomi\";\n readonly locale: \"fi\";\n}, {\n readonly label: \"Svenska\";\n readonly locale: \"sv\";\n}, {\n readonly label: \"Tiếng Việt\";\n readonly locale: \"vi\";\n}, {\n readonly label: \"Türkçe\";\n readonly locale: \"tr\";\n}, {\n readonly label: \"Ukrainian\";\n readonly locale: \"uk\";\n}, {\n readonly label: \"עברית\";\n readonly locale: \"he\";\n}, {\n readonly label: \"عربي\";\n readonly locale: \"ar\";\n}, {\n readonly label: \"فارسی\";\n readonly locale: \"fa\";\n}, {\n readonly label: \"کوردی\";\n readonly locale: \"ku\";\n}, {\n readonly label: \"नेपाली\";\n readonly locale: \"ne\";\n}, {\n readonly label: \"हिन्दी\";\n readonly locale: \"hi-in\";\n}, {\n readonly label: \"తెలుగు\";\n readonly locale: \"te\";\n}, {\n readonly label: \"ภาษาไทย\";\n readonly locale: \"th\";\n}, {\n readonly label: \"မြန်မာစာ\";\n readonly locale: \"my\";\n}, {\n readonly label: \"한국어\";\n readonly locale: \"ko-kr\";\n}, {\n readonly label: \"日本語\";\n readonly locale: \"ja\";\n}, {\n readonly label: \"简体中文\";\n readonly locale: \"zh-cn\";\n}, {\n readonly label: \"繁體中文 (台灣)\";\n readonly locale: \"zh-tw\";\n}]"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/translations/languages.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "LANGUAGES",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!lineShapeProps:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "lineShapeProps: "
},
{
"kind": "Content",
"text": "{\n color: import(\"../styles/StyleProp\")."
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
Add white (#3321) This PR adds white. It's available with Alt+T. ![Kapture 2024-04-01 at 18 32 22](https://github.com/tldraw/tldraw/assets/23072548/932c9621-ee09-403f-aacc-0226e7b03967) ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `feature` — New feature ### Release Notes - Adds secret white color.
2024-04-01 18:48:56 +00:00
"text": "<\"black\" | \"blue\" | \"green\" | \"grey\" | \"light-blue\" | \"light-green\" | \"light-red\" | \"light-violet\" | \"orange\" | \"red\" | \"violet\" | \"white\" | \"yellow\">;\n dash: import(\"../styles/StyleProp\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"dashed\" | \"dotted\" | \"draw\" | \"solid\">;\n points: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.DictValidator",
"canonicalReference": "@tldraw/validate!DictValidator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<string, {\n id: string;\n index: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "IndexKey",
"canonicalReference": "@tldraw/utils!IndexKey:type"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": ";\n x: number;\n y: number;\n } & {}>;\n size: import(\"../styles/StyleProp\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
[Snapping 2/5] Fix line-handle mid-point snapping (#2831) Currently, only the end handles of the line tool snap. It should be all of them. Line handles work kind of weirdly at the moment: instead of just storing the positions, we store full `TLHandle` objects complete with IDs, `canSnap`/`canBind` properties, etc. Currently, all the handles get written to the store with `canSnap: false`, when really it should be up to the shape util to decide which handles are snappable. This diff replaces the current handles map (from arbitrary ID to `TLHandle`) with just the data we need: a map from index to x/y. The extra information that the `Editor` needs for `TLHandle` is hydrated at runtime (with `canSnap` set to `true` this time!) Fixes TLD-2200 This PR is part of a series - please don't merge it until the things before it have landed! 1. #2827 2. #2831 (you are here) 3. #2793 4. #2841 5. #2845 ### Change Type - [x] `major` — Breaking change [^1]: publishes a `patch` release, for devDependencies use `internal` [^2]: will not publish a new version ### Test Plan 1. Create a funky line shape on tldraw.com 2. Paste it into staging and make sure it comes across ok 3. Make some funky line shape in staging - make sure you use dragging, mid-point creation, and shift-clicking - [x] Unit Tests ### Release Notes - Simplify the contents of `TLLineShape.props.handles`
2024-02-15 10:27:55 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"l\" | \"m\" | \"s\" | \"xl\">;\n spline: import(\"../styles/StyleProp\")."
[Snapping 2/5] Fix line-handle mid-point snapping (#2831) Currently, only the end handles of the line tool snap. It should be all of them. Line handles work kind of weirdly at the moment: instead of just storing the positions, we store full `TLHandle` objects complete with IDs, `canSnap`/`canBind` properties, etc. Currently, all the handles get written to the store with `canSnap: false`, when really it should be up to the shape util to decide which handles are snappable. This diff replaces the current handles map (from arbitrary ID to `TLHandle`) with just the data we need: a map from index to x/y. The extra information that the `Editor` needs for `TLHandle` is hydrated at runtime (with `canSnap` set to `true` this time!) Fixes TLD-2200 This PR is part of a series - please don't merge it until the things before it have landed! 1. #2827 2. #2831 (you are here) 3. #2793 4. #2841 5. #2845 ### Change Type - [x] `major` — Breaking change [^1]: publishes a `patch` release, for devDependencies use `internal` [^2]: will not publish a new version ### Test Plan 1. Create a funky line shape on tldraw.com 2. Paste it into staging and make sure it comes across ok 3. Make some funky line shape in staging - make sure you use dragging, mid-point creation, and shift-clicking - [x] Unit Tests ### Release Notes - Simplify the contents of `TLLineShape.props.handles`
2024-02-15 10:27:55 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"cubic\" | \"line\">;\n}"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLLineShape.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "lineShapeProps",
"variableTypeTokenRange": {
"startIndex": 1,
[handles] Line shape handles -> points (#2856) This PR replaces the line shape's `handles` prop with `points`, an array of `VecModel`s. ### Change Type - [x] `minor` — New feature ### Test Plan - [x] Unit Tests - [ ] End to end tests
2024-02-19 17:10:31 +00:00
"endIndex": 14
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!LineShapeSplineStyle:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "LineShapeSplineStyle: "
},
{
"kind": "Content",
"text": "import(\"../styles/StyleProp\")."
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "<\"cubic\" | \"line\">"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLLineShape.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "LineShapeSplineStyle",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 4
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!noteShapeProps:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "noteShapeProps: "
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "{\n align: import(\"..\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"end-legacy\" | \"end\" | \"middle-legacy\" | \"middle\" | \"start-legacy\" | \"start\">;\n color: import(\"..\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"black\" | \"blue\" | \"green\" | \"grey\" | \"light-blue\" | \"light-green\" | \"light-red\" | \"light-violet\" | \"orange\" | \"red\" | \"violet\" | \"white\" | \"yellow\">;\n font: import(\"..\")."
Stickies: release candidate (#3249) This PR is the target for the stickies PRs that are moving forward. It should collect changes. - [x] New icon - [x] Improved shadows - [x] Shadow LOD - [x] New colors / theme options - [x] Shrink text size to avoid word breaks on the x axis - [x] Hide indicator whilst typing (reverted) - [x] Adjacent note positions - [x] buttons / clone handles - [x] position helpers for creating / translating (pits) - [x] keyboard shortcuts: (Tab, Shift+tab (RTL aware), Cmd-Enter, Shift+Cmd+enter) - [x] multiple shape translating - [x] Text editing - [x] Edit on type (feature flagged) - [x] click goes in correct place - [x] Notes as parents (reverted) - [x] Update colors - [x] Update SVG appearance ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `feature` — New feature ### Test Plan Todo: fold in test plans for child PRs ### Unit tests: - [ ] Shrink text size to avoid word breaks on the x axis - [x] Adjacent notes - [x] buttons (clone handles) - [x] position helpers (pits) - [x] keyboard shortcuts: (Tab, Shift+tab (RTL aware), Cmd-Enter, Shift+Cmd+enter) - [ ] Text editing - [ ] Edit on type - [ ] click goes in correct place ### Release Notes - Improves sticky notes (see list) --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com> Co-authored-by: alex <alex@dytry.ch> Co-authored-by: Mitja Bezenšek <mitja.bezensek@gmail.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Lu[ke] Wilson <l2wilson94@gmail.com> Co-authored-by: huppy-bot[bot] <128400622+huppy-bot[bot]@users.noreply.github.com>
2024-04-14 18:40:02 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
Stickies: release candidate (#3249) This PR is the target for the stickies PRs that are moving forward. It should collect changes. - [x] New icon - [x] Improved shadows - [x] Shadow LOD - [x] New colors / theme options - [x] Shrink text size to avoid word breaks on the x axis - [x] Hide indicator whilst typing (reverted) - [x] Adjacent note positions - [x] buttons / clone handles - [x] position helpers for creating / translating (pits) - [x] keyboard shortcuts: (Tab, Shift+tab (RTL aware), Cmd-Enter, Shift+Cmd+enter) - [x] multiple shape translating - [x] Text editing - [x] Edit on type (feature flagged) - [x] click goes in correct place - [x] Notes as parents (reverted) - [x] Update colors - [x] Update SVG appearance ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `feature` — New feature ### Test Plan Todo: fold in test plans for child PRs ### Unit tests: - [ ] Shrink text size to avoid word breaks on the x axis - [x] Adjacent notes - [x] buttons (clone handles) - [x] position helpers (pits) - [x] keyboard shortcuts: (Tab, Shift+tab (RTL aware), Cmd-Enter, Shift+Cmd+enter) - [ ] Text editing - [ ] Edit on type - [ ] click goes in correct place ### Release Notes - Improves sticky notes (see list) --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com> Co-authored-by: alex <alex@dytry.ch> Co-authored-by: Mitja Bezenšek <mitja.bezensek@gmail.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Lu[ke] Wilson <l2wilson94@gmail.com> Co-authored-by: huppy-bot[bot] <128400622+huppy-bot[bot]@users.noreply.github.com>
2024-04-14 18:40:02 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"draw\" | \"mono\" | \"sans\" | \"serif\">;\n fontSizeAdjustment: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<number>;\n growY: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<number>;\n size: import(\"..\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"l\" | \"m\" | \"s\" | \"xl\">;\n text: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<string>;\n url: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<string>;\n verticalAlign: import(\"..\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"end\" | \"middle\" | \"start\">;\n}"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLNoteShape.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "noteShapeProps",
"variableTypeTokenRange": {
"startIndex": 1,
Stickies: release candidate (#3249) This PR is the target for the stickies PRs that are moving forward. It should collect changes. - [x] New icon - [x] Improved shadows - [x] Shadow LOD - [x] New colors / theme options - [x] Shrink text size to avoid word breaks on the x axis - [x] Hide indicator whilst typing (reverted) - [x] Adjacent note positions - [x] buttons / clone handles - [x] position helpers for creating / translating (pits) - [x] keyboard shortcuts: (Tab, Shift+tab (RTL aware), Cmd-Enter, Shift+Cmd+enter) - [x] multiple shape translating - [x] Text editing - [x] Edit on type (feature flagged) - [x] click goes in correct place - [x] Notes as parents (reverted) - [x] Update colors - [x] Update SVG appearance ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `feature` — New feature ### Test Plan Todo: fold in test plans for child PRs ### Unit tests: - [ ] Shrink text size to avoid word breaks on the x axis - [x] Adjacent notes - [x] buttons (clone handles) - [x] position helpers (pits) - [x] keyboard shortcuts: (Tab, Shift+tab (RTL aware), Cmd-Enter, Shift+Cmd+enter) - [ ] Text editing - [ ] Edit on type - [ ] click goes in correct place ### Release Notes - Improves sticky notes (see list) --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com> Co-authored-by: alex <alex@dytry.ch> Co-authored-by: Mitja Bezenšek <mitja.bezensek@gmail.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Lu[ke] Wilson <l2wilson94@gmail.com> Co-authored-by: huppy-bot[bot] <128400622+huppy-bot[bot]@users.noreply.github.com>
2024-04-14 18:40:02 +00:00
"endIndex": 20
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!PageRecordType:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "PageRecordType: "
},
{
"kind": "Content",
"text": "import(\"@tldraw/store\")."
},
{
"kind": "Reference",
"text": "RecordType",
"canonicalReference": "@tldraw/store!RecordType:class"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLPage",
"canonicalReference": "@tldraw/tlschema!TLPage:interface"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": ", \"index\" | \"name\">"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/records/TLPage.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "PageRecordType",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 6
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!parentIdValidator:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "parentIdValidator: "
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLParentId",
"canonicalReference": "@tldraw/tlschema!TLParentId:type"
},
{
"kind": "Content",
"text": ">"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLBaseShape.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "parentIdValidator",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!PointerRecordType:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "PointerRecordType: "
},
{
"kind": "Content",
"text": "import(\"@tldraw/store\")."
},
{
"kind": "Reference",
"text": "RecordType",
"canonicalReference": "@tldraw/store!RecordType:class"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLPointer",
"canonicalReference": "@tldraw/tlschema!~TLPointer:interface"
},
{
"kind": "Content",
"text": ", never>"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLPointer.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "PointerRecordType",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 6
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!SchemaShapeInfo:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type SchemaShapeInfo = "
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "{\n meta?: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "Record",
"canonicalReference": "!Record:type"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<string, "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "AnyValidator",
"canonicalReference": "@tldraw/tlschema!~AnyValidator:type"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": ">;\n migrations?: "
Faster validations + record reference stability at the same time (#2848) This PR adds a validation mode whereby previous known-to-be-valid values can be used to speed up the validation process itself. At the same time it enables us to do fine-grained equality checking on records much more quickly than by using something like lodash isEqual, and using that we can prevent triggering effects for record updates that don't actually alter any values in the store. Here's some preliminary perf testing of average time spent in `store.put()` during some common interactions | task | before (ms) | after (ms) | | ---- | ---- | ---- | | drawing lines | 0.0403 | 0.0214 | | drawing boxes | 0.0408 | 0.0348 | | translating lines | 0.0352 | 0.0042 | | translating boxes | 0.0051 | 0.0032 | | rotating lines | 0.0312 | 0.0065 | | rotating boxes | 0.0053 | 0.0035 | | brush selecting boxes | 0.0200 | 0.0232 | | traversal with shapes | 0.0130 | 0.0108 | | traversal without shapes | 0.0201 | 0.0173 | **traversal** means moving the camera and pointer around the canvas #### Discussion At the scale of hundredths of a millisecond these .put operations are so fast that even if they became literally instantaneous the change would not be human perceptible. That said, there is an overall marked improvement here. Especially for dealing with draw shapes. These figures are also mostly in line with expectations, aside from a couple of things: - I don't understand why the `brush selecting boxes` task got slower after the change. - I don't understand why the `traversal` tasks are slower than the `translating boxes` task, both before and after. I would expect that .putting shape records would be much slower than .putting pointer/camera records (since the latter have fewer and simpler properties) ### Change Type - [x] `patch` — Bug fix ### 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.
2024-02-20 12:35:25 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "LegacyMigrations",
"canonicalReference": "@tldraw/store!LegacyMigrations:interface"
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
"text": "MigrationSequence",
"canonicalReference": "@tldraw/store!MigrationSequence:interface"
Faster validations + record reference stability at the same time (#2848) This PR adds a validation mode whereby previous known-to-be-valid values can be used to speed up the validation process itself. At the same time it enables us to do fine-grained equality checking on records much more quickly than by using something like lodash isEqual, and using that we can prevent triggering effects for record updates that don't actually alter any values in the store. Here's some preliminary perf testing of average time spent in `store.put()` during some common interactions | task | before (ms) | after (ms) | | ---- | ---- | ---- | | drawing lines | 0.0403 | 0.0214 | | drawing boxes | 0.0408 | 0.0348 | | translating lines | 0.0352 | 0.0042 | | translating boxes | 0.0051 | 0.0032 | | rotating lines | 0.0312 | 0.0065 | | rotating boxes | 0.0053 | 0.0035 | | brush selecting boxes | 0.0200 | 0.0232 | | traversal with shapes | 0.0130 | 0.0108 | | traversal without shapes | 0.0201 | 0.0173 | **traversal** means moving the camera and pointer around the canvas #### Discussion At the scale of hundredths of a millisecond these .put operations are so fast that even if they became literally instantaneous the change would not be human perceptible. That said, there is an overall marked improvement here. Especially for dealing with draw shapes. These figures are also mostly in line with expectations, aside from a couple of things: - I don't understand why the `brush selecting boxes` task got slower after the change. - I don't understand why the `traversal` tasks are slower than the `translating boxes` task, both before and after. I would expect that .putting shape records would be much slower than .putting pointer/camera records (since the latter have fewer and simpler properties) ### Change Type - [x] `patch` — Bug fix ### 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.
2024-02-20 12:35:25 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": " | "
},
{
"kind": "Reference",
"text": "TLShapePropsMigrations",
"canonicalReference": "@tldraw/tlschema!TLShapePropsMigrations:type"
},
{
"kind": "Content",
"text": ";\n props?: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "Record",
"canonicalReference": "!Record:type"
},
{
"kind": "Content",
Faster validations + record reference stability at the same time (#2848) This PR adds a validation mode whereby previous known-to-be-valid values can be used to speed up the validation process itself. At the same time it enables us to do fine-grained equality checking on records much more quickly than by using something like lodash isEqual, and using that we can prevent triggering effects for record updates that don't actually alter any values in the store. Here's some preliminary perf testing of average time spent in `store.put()` during some common interactions | task | before (ms) | after (ms) | | ---- | ---- | ---- | | drawing lines | 0.0403 | 0.0214 | | drawing boxes | 0.0408 | 0.0348 | | translating lines | 0.0352 | 0.0042 | | translating boxes | 0.0051 | 0.0032 | | rotating lines | 0.0312 | 0.0065 | | rotating boxes | 0.0053 | 0.0035 | | brush selecting boxes | 0.0200 | 0.0232 | | traversal with shapes | 0.0130 | 0.0108 | | traversal without shapes | 0.0201 | 0.0173 | **traversal** means moving the camera and pointer around the canvas #### Discussion At the scale of hundredths of a millisecond these .put operations are so fast that even if they became literally instantaneous the change would not be human perceptible. That said, there is an overall marked improvement here. Especially for dealing with draw shapes. These figures are also mostly in line with expectations, aside from a couple of things: - I don't understand why the `brush selecting boxes` task got slower after the change. - I don't understand why the `traversal` tasks are slower than the `translating boxes` task, both before and after. I would expect that .putting shape records would be much slower than .putting pointer/camera records (since the latter have fewer and simpler properties) ### Change Type - [x] `patch` — Bug fix ### 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.
2024-02-20 12:35:25 +00:00
"text": "<string, "
},
{
"kind": "Reference",
"text": "AnyValidator",
"canonicalReference": "@tldraw/tlschema!~AnyValidator:type"
},
{
"kind": "Content",
"text": ">;\n}"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/createTLSchema.ts",
"releaseTag": "Public",
"name": "SchemaShapeInfo",
"typeTokenRange": {
"startIndex": 1,
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"endIndex": 16
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!shapeIdValidator:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "shapeIdValidator: "
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLShapeId",
"canonicalReference": "@tldraw/tlschema!TLShapeId:type"
},
{
"kind": "Content",
"text": ">"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLBaseShape.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "shapeIdValidator",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!ShapeProps:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type ShapeProps<Shape extends "
},
{
"kind": "Reference",
"text": "TLBaseShape",
"canonicalReference": "@tldraw/tlschema!TLBaseShape:interface"
},
{
"kind": "Content",
"text": "<any, any>"
},
{
"kind": "Content",
"text": "> = "
},
{
"kind": "Content",
"text": "{\n [K in keyof Shape['props']]: "
},
{
"kind": "Reference",
"text": "T.Validatable",
"canonicalReference": "@tldraw/validate!Validatable:type"
},
{
"kind": "Content",
"text": "<Shape['props'][K]>;\n}"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLBaseShape.ts",
"releaseTag": "Public",
"name": "ShapeProps",
"typeParameters": [
{
"typeParameterName": "Shape",
"constraintTokenRange": {
"startIndex": 1,
"endIndex": 3
},
"defaultTypeTokenRange": {
"startIndex": 0,
"endIndex": 0
}
}
],
"typeTokenRange": {
"startIndex": 4,
"endIndex": 7
}
},
Stickies: release candidate (#3249) This PR is the target for the stickies PRs that are moving forward. It should collect changes. - [x] New icon - [x] Improved shadows - [x] Shadow LOD - [x] New colors / theme options - [x] Shrink text size to avoid word breaks on the x axis - [x] Hide indicator whilst typing (reverted) - [x] Adjacent note positions - [x] buttons / clone handles - [x] position helpers for creating / translating (pits) - [x] keyboard shortcuts: (Tab, Shift+tab (RTL aware), Cmd-Enter, Shift+Cmd+enter) - [x] multiple shape translating - [x] Text editing - [x] Edit on type (feature flagged) - [x] click goes in correct place - [x] Notes as parents (reverted) - [x] Update colors - [x] Update SVG appearance ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `feature` — New feature ### Test Plan Todo: fold in test plans for child PRs ### Unit tests: - [ ] Shrink text size to avoid word breaks on the x axis - [x] Adjacent notes - [x] buttons (clone handles) - [x] position helpers (pits) - [x] keyboard shortcuts: (Tab, Shift+tab (RTL aware), Cmd-Enter, Shift+Cmd+enter) - [ ] Text editing - [ ] Edit on type - [ ] click goes in correct place ### Release Notes - Improves sticky notes (see list) --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com> Co-authored-by: alex <alex@dytry.ch> Co-authored-by: Mitja Bezenšek <mitja.bezensek@gmail.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Lu[ke] Wilson <l2wilson94@gmail.com> Co-authored-by: huppy-bot[bot] <128400622+huppy-bot[bot]@users.noreply.github.com>
2024-04-14 18:40:02 +00:00
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!ShapePropsType:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type ShapePropsType<Config extends "
},
{
"kind": "Reference",
"text": "Record",
"canonicalReference": "!Record:type"
},
{
"kind": "Content",
"text": "<string, "
},
{
"kind": "Reference",
"text": "T.Validatable",
"canonicalReference": "@tldraw/validate!Validatable:type"
},
{
"kind": "Content",
"text": "<any>>"
},
{
"kind": "Content",
"text": "> = "
},
{
"kind": "Reference",
"text": "Expand",
"canonicalReference": "@tldraw/utils!Expand:type"
},
{
"kind": "Content",
"text": "<{\n [K in keyof Config]: "
},
{
"kind": "Reference",
"text": "T.TypeOf",
"canonicalReference": "@tldraw/validate!TypeOf:type"
},
{
"kind": "Content",
"text": "<Config[K]>;\n}>"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLBaseShape.ts",
"releaseTag": "Public",
"name": "ShapePropsType",
"typeParameters": [
{
"typeParameterName": "Config",
"constraintTokenRange": {
"startIndex": 1,
"endIndex": 5
},
"defaultTypeTokenRange": {
"startIndex": 0,
"endIndex": 0
}
}
],
"typeTokenRange": {
"startIndex": 6,
"endIndex": 10
}
},
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
{
"kind": "Class",
"canonicalReference": "@tldraw/tlschema!StyleProp:class",
[fix] broken docs link (#2062) This PR fixes a broken link in the StyleProp docs. ### Change Type - [x] `internal` — Any other changes that don't affect the published package[^2]
2023-10-10 13:23:49 +00:00
"docComment": "/**\n * A `StyleProp` is a property of a shape that follows some special rules.\n *\n * 1. The same value can be set on lots of shapes at the same time.\n *\n * 2. The last used value is automatically saved and applied to new shapes.\n *\n * For example, {@link DefaultColorStyle} is a style prop used by tldraw's default shapes to set their color. If you try selecting several shapes on tldraw.com and changing their color, you'll see that the color is applied to all of them. Then, if you draw a new shape, it'll have the same color as the one you just set.\n *\n * You can use styles in your own shapes by either defining your own (see {@link StyleProp.define} and {@link StyleProp.defineEnum}) or using tldraw's default ones, like {@link DefaultColorStyle}. When you define a shape, pass a `props` object describing all of your shape's properties, using `StyleProp`s for the ones you want to be styles. See the {@link https://github.com/tldraw/tldraw/tree/main/apps/examples | custom styles example} for more.\n *\n * @remarks\n *\n * The constructor for this class is marked as internal. Third-party code should not call the constructor directly or create subclasses that extend the `StyleProp` class.\n *\n * @public\n */\n",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"excerptTokens": [
{
"kind": "Content",
"text": "export declare class StyleProp<Type> implements "
},
{
"kind": "Reference",
"text": "T.Validatable",
"canonicalReference": "@tldraw/validate!Validatable:type"
},
{
"kind": "Content",
"text": "<Type>"
},
{
"kind": "Content",
"text": " "
}
],
"fileUrlPath": "packages/tlschema/src/styles/StyleProp.ts",
"releaseTag": "Public",
"typeParameters": [
{
"typeParameterName": "Type",
"constraintTokenRange": {
"startIndex": 0,
"endIndex": 0
},
"defaultTypeTokenRange": {
"startIndex": 0,
"endIndex": 0
}
}
],
"isAbstract": false,
"name": "StyleProp",
"preserveMemberOrder": false,
"members": [
{
"kind": "Property",
"canonicalReference": "@tldraw/tlschema!StyleProp#defaultValue:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "readonly defaultValue: "
},
{
"kind": "Content",
"text": "Type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": true,
"isOptional": false,
"releaseTag": "Public",
"name": "defaultValue",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
},
"isStatic": false,
"isProtected": false,
"isAbstract": false
},
{
"kind": "Method",
"canonicalReference": "@tldraw/tlschema!StyleProp.define:member(1)",
"docComment": "/**\n * Define a new {@link StyleProp}.\n *\n * @param uniqueId - Each StyleProp must have a unique ID. We recommend you prefix this with your app/library name.\n *\n * @param options - - `defaultValue`: The default value for this style prop.\n *\n * - `type`: Optionally, describe what type of data you expect for this style prop.\n *\n * @example\n * ```ts\n * import {T} from '@tldraw/validate'\n * import {StyleProp} from '@tldraw/tlschema'\n *\n * const MyLineWidthProp = StyleProp.define('myApp:lineWidth', {\n * defaultValue: 1,\n * type: T.number,\n * })\n * ```\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "static define<Type>(uniqueId: "
},
{
"kind": "Content",
"text": "string"
},
{
"kind": "Content",
"text": ", options: "
},
{
"kind": "Content",
"text": "{\n defaultValue: Type;\n type?: "
},
{
"kind": "Reference",
"text": "T.Validatable",
"canonicalReference": "@tldraw/validate!Validatable:type"
},
{
"kind": "Content",
"text": "<Type>;\n }"
},
{
"kind": "Content",
"text": "): "
},
{
"kind": "Reference",
"text": "StyleProp",
"canonicalReference": "@tldraw/tlschema!StyleProp:class"
},
{
"kind": "Content",
"text": "<Type>"
},
{
"kind": "Content",
"text": ";"
}
],
"typeParameters": [
{
"typeParameterName": "Type",
"constraintTokenRange": {
"startIndex": 0,
"endIndex": 0
},
"defaultTypeTokenRange": {
"startIndex": 0,
"endIndex": 0
}
}
],
"isStatic": true,
"returnTypeTokenRange": {
"startIndex": 7,
"endIndex": 9
},
"releaseTag": "Public",
"isProtected": false,
"overloadIndex": 1,
"parameters": [
{
"parameterName": "uniqueId",
"parameterTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
},
"isOptional": false
},
{
"parameterName": "options",
"parameterTypeTokenRange": {
"startIndex": 3,
"endIndex": 6
},
"isOptional": false
}
],
"isOptional": false,
"isAbstract": false,
"name": "define"
},
{
"kind": "Method",
"canonicalReference": "@tldraw/tlschema!StyleProp.defineEnum:member(1)",
"docComment": "/**\n * Define a new {@link StyleProp} as a list of possible values.\n *\n * @param uniqueId - Each StyleProp must have a unique ID. We recommend you prefix this with your app/library name.\n *\n * @param options - - `defaultValue`: The default value for this style prop.\n *\n * - `values`: An array of possible values of this style prop.\n *\n * @example\n * ```ts\n * import {StyleProp} from '@tldraw/tlschema'\n *\n * const MySizeProp = StyleProp.defineEnum('myApp:size', {\n * defaultValue: 'medium',\n * values: ['small', 'medium', 'large'],\n * })\n * ```\n *\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "static defineEnum<const Values extends "
},
{
"kind": "Content",
"text": "readonly unknown[]"
},
{
"kind": "Content",
"text": ">(uniqueId: "
},
{
"kind": "Content",
"text": "string"
},
{
"kind": "Content",
"text": ", options: "
},
{
"kind": "Content",
"text": "{\n defaultValue: Values[number];\n values: Values;\n }"
},
{
"kind": "Content",
"text": "): "
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
"text": "<Values[number]>"
},
{
"kind": "Content",
"text": ";"
}
],
"typeParameters": [
{
"typeParameterName": "Values",
"constraintTokenRange": {
"startIndex": 1,
"endIndex": 2
},
"defaultTypeTokenRange": {
"startIndex": 0,
"endIndex": 0
}
}
],
"isStatic": true,
"returnTypeTokenRange": {
"startIndex": 7,
"endIndex": 9
},
"releaseTag": "Public",
"isProtected": false,
"overloadIndex": 1,
"parameters": [
{
"parameterName": "uniqueId",
"parameterTypeTokenRange": {
"startIndex": 3,
"endIndex": 4
},
"isOptional": false
},
{
"parameterName": "options",
"parameterTypeTokenRange": {
"startIndex": 5,
"endIndex": 6
},
"isOptional": false
}
],
"isOptional": false,
"isAbstract": false,
"name": "defineEnum"
},
{
"kind": "Property",
"canonicalReference": "@tldraw/tlschema!StyleProp#id:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "readonly id: "
},
{
"kind": "Content",
"text": "string"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": true,
"isOptional": false,
"releaseTag": "Public",
"name": "id",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
},
"isStatic": false,
"isProtected": false,
"isAbstract": false
},
{
"kind": "Property",
"canonicalReference": "@tldraw/tlschema!StyleProp#type:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "readonly type: "
},
{
"kind": "Reference",
"text": "T.Validatable",
"canonicalReference": "@tldraw/validate!Validatable:type"
},
{
"kind": "Content",
"text": "<Type>"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": true,
"isOptional": false,
"releaseTag": "Public",
"name": "type",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 3
},
"isStatic": false,
"isProtected": false,
"isAbstract": false
},
{
"kind": "Method",
"canonicalReference": "@tldraw/tlschema!StyleProp#validate:member(1)",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "validate(value: "
},
{
"kind": "Content",
"text": "unknown"
},
{
"kind": "Content",
"text": "): "
},
{
"kind": "Content",
"text": "Type"
},
{
"kind": "Content",
"text": ";"
}
],
"isStatic": false,
"returnTypeTokenRange": {
"startIndex": 3,
"endIndex": 4
},
"releaseTag": "Public",
"isProtected": false,
"overloadIndex": 1,
"parameters": [
{
"parameterName": "value",
"parameterTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
},
"isOptional": false
}
],
"isOptional": false,
"isAbstract": false,
"name": "validate"
Faster validations + record reference stability at the same time (#2848) This PR adds a validation mode whereby previous known-to-be-valid values can be used to speed up the validation process itself. At the same time it enables us to do fine-grained equality checking on records much more quickly than by using something like lodash isEqual, and using that we can prevent triggering effects for record updates that don't actually alter any values in the store. Here's some preliminary perf testing of average time spent in `store.put()` during some common interactions | task | before (ms) | after (ms) | | ---- | ---- | ---- | | drawing lines | 0.0403 | 0.0214 | | drawing boxes | 0.0408 | 0.0348 | | translating lines | 0.0352 | 0.0042 | | translating boxes | 0.0051 | 0.0032 | | rotating lines | 0.0312 | 0.0065 | | rotating boxes | 0.0053 | 0.0035 | | brush selecting boxes | 0.0200 | 0.0232 | | traversal with shapes | 0.0130 | 0.0108 | | traversal without shapes | 0.0201 | 0.0173 | **traversal** means moving the camera and pointer around the canvas #### Discussion At the scale of hundredths of a millisecond these .put operations are so fast that even if they became literally instantaneous the change would not be human perceptible. That said, there is an overall marked improvement here. Especially for dealing with draw shapes. These figures are also mostly in line with expectations, aside from a couple of things: - I don't understand why the `brush selecting boxes` task got slower after the change. - I don't understand why the `traversal` tasks are slower than the `translating boxes` task, both before and after. I would expect that .putting shape records would be much slower than .putting pointer/camera records (since the latter have fewer and simpler properties) ### Change Type - [x] `patch` — Bug fix ### 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.
2024-02-20 12:35:25 +00:00
},
{
"kind": "Method",
"canonicalReference": "@tldraw/tlschema!StyleProp#validateUsingKnownGoodVersion:member(1)",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "validateUsingKnownGoodVersion(prevValue: "
},
{
"kind": "Content",
"text": "Type"
},
{
"kind": "Content",
"text": ", newValue: "
},
{
"kind": "Content",
"text": "unknown"
},
{
"kind": "Content",
"text": "): "
},
{
"kind": "Content",
"text": "Type"
},
{
"kind": "Content",
"text": ";"
}
],
"isStatic": false,
"returnTypeTokenRange": {
"startIndex": 5,
"endIndex": 6
},
"releaseTag": "Public",
"isProtected": false,
"overloadIndex": 1,
"parameters": [
{
"parameterName": "prevValue",
"parameterTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
},
"isOptional": false
},
{
"parameterName": "newValue",
"parameterTypeTokenRange": {
"startIndex": 3,
"endIndex": 4
},
"isOptional": false
}
],
"isOptional": false,
"isAbstract": false,
"name": "validateUsingKnownGoodVersion"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"implementsTokenRanges": [
{
"startIndex": 1,
"endIndex": 3
}
]
},
Faster validations + record reference stability at the same time (#2848) This PR adds a validation mode whereby previous known-to-be-valid values can be used to speed up the validation process itself. At the same time it enables us to do fine-grained equality checking on records much more quickly than by using something like lodash isEqual, and using that we can prevent triggering effects for record updates that don't actually alter any values in the store. Here's some preliminary perf testing of average time spent in `store.put()` during some common interactions | task | before (ms) | after (ms) | | ---- | ---- | ---- | | drawing lines | 0.0403 | 0.0214 | | drawing boxes | 0.0408 | 0.0348 | | translating lines | 0.0352 | 0.0042 | | translating boxes | 0.0051 | 0.0032 | | rotating lines | 0.0312 | 0.0065 | | rotating boxes | 0.0053 | 0.0035 | | brush selecting boxes | 0.0200 | 0.0232 | | traversal with shapes | 0.0130 | 0.0108 | | traversal without shapes | 0.0201 | 0.0173 | **traversal** means moving the camera and pointer around the canvas #### Discussion At the scale of hundredths of a millisecond these .put operations are so fast that even if they became literally instantaneous the change would not be human perceptible. That said, there is an overall marked improvement here. Especially for dealing with draw shapes. These figures are also mostly in line with expectations, aside from a couple of things: - I don't understand why the `brush selecting boxes` task got slower after the change. - I don't understand why the `traversal` tasks are slower than the `translating boxes` task, both before and after. I would expect that .putting shape records would be much slower than .putting pointer/camera records (since the latter have fewer and simpler properties) ### Change Type - [x] `patch` — Bug fix ### 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.
2024-02-20 12:35:25 +00:00
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!StylePropValue:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type StylePropValue<T extends "
},
{
"kind": "Reference",
"text": "StyleProp",
"canonicalReference": "@tldraw/tlschema!StyleProp:class"
},
{
"kind": "Content",
"text": "<any>"
},
{
"kind": "Content",
"text": "> = "
},
{
"kind": "Content",
"text": "T extends "
},
{
"kind": "Reference",
"text": "StyleProp",
"canonicalReference": "@tldraw/tlschema!StyleProp:class"
},
{
"kind": "Content",
"text": "<infer U> ? U : never"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/styles/StyleProp.ts",
"releaseTag": "Public",
"name": "StylePropValue",
"typeParameters": [
{
"typeParameterName": "T",
"constraintTokenRange": {
"startIndex": 1,
"endIndex": 3
},
"defaultTypeTokenRange": {
"startIndex": 0,
"endIndex": 0
}
}
],
"typeTokenRange": {
"startIndex": 4,
"endIndex": 7
}
},
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!textShapeProps:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "textShapeProps: "
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "{\n align: import(\"..\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"end-legacy\" | \"end\" | \"middle-legacy\" | \"middle\" | \"start-legacy\" | \"start\">;\n autoSize: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<boolean>;\n color: import(\"..\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"black\" | \"blue\" | \"green\" | \"grey\" | \"light-blue\" | \"light-green\" | \"light-red\" | \"light-violet\" | \"orange\" | \"red\" | \"violet\" | \"white\" | \"yellow\">;\n font: import(\"..\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"draw\" | \"mono\" | \"sans\" | \"serif\">;\n scale: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<number>;\n size: import(\"..\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "EnumStyleProp",
"canonicalReference": "@tldraw/tlschema!EnumStyleProp:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<\"l\" | \"m\" | \"s\" | \"xl\">;\n text: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<string>;\n w: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<number>;\n}"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLTextShape.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "textShapeProps",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 18
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!TL_CANVAS_UI_COLOR_TYPES:var",
"docComment": "/**\n * The colors used by tldraw's default shapes.\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "TL_CANVAS_UI_COLOR_TYPES: "
},
{
"kind": "Reference",
"text": "Set",
"canonicalReference": "!Set:interface"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "<\"accent\" | \"black\" | \"laser\" | \"muted-1\" | \"selection-fill\" | \"selection-stroke\" | \"white\">"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/misc/TLColor.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "TL_CANVAS_UI_COLOR_TYPES",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 3
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLArrowShape:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLArrowShape = "
},
{
"kind": "Reference",
"text": "TLBaseShape",
"canonicalReference": "@tldraw/tlschema!TLBaseShape:interface"
},
{
"kind": "Content",
"text": "<'arrow', "
},
{
"kind": "Reference",
"text": "TLArrowShapeProps",
"canonicalReference": "@tldraw/tlschema!TLArrowShapeProps:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLArrowShape.ts",
"releaseTag": "Public",
"name": "TLArrowShape",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLArrowShapeArrowheadStyle:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLArrowShapeArrowheadStyle = "
},
{
"kind": "Reference",
"text": "T.TypeOf",
"canonicalReference": "@tldraw/validate!TypeOf:type"
},
{
"kind": "Content",
"text": "<typeof "
},
{
"kind": "Reference",
"text": "ArrowShapeArrowheadStartStyle",
"canonicalReference": "@tldraw/tlschema!ArrowShapeArrowheadStartStyle:var"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLArrowShape.ts",
"releaseTag": "Public",
"name": "TLArrowShapeArrowheadStyle",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLArrowShapeProps:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLArrowShapeProps = "
},
{
"kind": "Reference",
"text": "ShapePropsType",
Stickies: release candidate (#3249) This PR is the target for the stickies PRs that are moving forward. It should collect changes. - [x] New icon - [x] Improved shadows - [x] Shadow LOD - [x] New colors / theme options - [x] Shrink text size to avoid word breaks on the x axis - [x] Hide indicator whilst typing (reverted) - [x] Adjacent note positions - [x] buttons / clone handles - [x] position helpers for creating / translating (pits) - [x] keyboard shortcuts: (Tab, Shift+tab (RTL aware), Cmd-Enter, Shift+Cmd+enter) - [x] multiple shape translating - [x] Text editing - [x] Edit on type (feature flagged) - [x] click goes in correct place - [x] Notes as parents (reverted) - [x] Update colors - [x] Update SVG appearance ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `feature` — New feature ### Test Plan Todo: fold in test plans for child PRs ### Unit tests: - [ ] Shrink text size to avoid word breaks on the x axis - [x] Adjacent notes - [x] buttons (clone handles) - [x] position helpers (pits) - [x] keyboard shortcuts: (Tab, Shift+tab (RTL aware), Cmd-Enter, Shift+Cmd+enter) - [ ] Text editing - [ ] Edit on type - [ ] click goes in correct place ### Release Notes - Improves sticky notes (see list) --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com> Co-authored-by: alex <alex@dytry.ch> Co-authored-by: Mitja Bezenšek <mitja.bezensek@gmail.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Lu[ke] Wilson <l2wilson94@gmail.com> Co-authored-by: huppy-bot[bot] <128400622+huppy-bot[bot]@users.noreply.github.com>
2024-04-14 18:40:02 +00:00
"canonicalReference": "@tldraw/tlschema!ShapePropsType:type"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": "<typeof "
},
{
"kind": "Reference",
"text": "arrowShapeProps",
"canonicalReference": "@tldraw/tlschema!arrowShapeProps:var"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLArrowShape.ts",
"releaseTag": "Public",
"name": "TLArrowShapeProps",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLArrowShapeTerminal:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLArrowShapeTerminal = "
},
{
"kind": "Reference",
"text": "T.TypeOf",
"canonicalReference": "@tldraw/validate!TypeOf:type"
},
{
"kind": "Content",
"text": "<typeof "
},
{
"kind": "Reference",
"text": "ArrowShapeTerminal",
"canonicalReference": "@tldraw/tlschema!~ArrowShapeTerminal:var"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLArrowShape.ts",
"releaseTag": "Public",
"name": "TLArrowShapeTerminal",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLAsset:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLAsset = "
},
{
"kind": "Reference",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "TLBookmarkAsset",
"canonicalReference": "@tldraw/tlschema!TLBookmarkAsset:type"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "TLImageAsset",
"canonicalReference": "@tldraw/tlschema!TLImageAsset:type"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "TLVideoAsset",
"canonicalReference": "@tldraw/tlschema!TLVideoAsset:type"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLAsset.ts",
"releaseTag": "Public",
"name": "TLAsset",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 6
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLAssetId:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLAssetId = "
},
{
"kind": "Reference",
"text": "RecordId",
"canonicalReference": "@tldraw/store!RecordId:type"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLBaseAsset",
"canonicalReference": "@tldraw/tlschema!TLBaseAsset:interface"
},
{
"kind": "Content",
"text": "<any, any>>"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLAsset.ts",
"releaseTag": "Public",
"name": "TLAssetId",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLAssetPartial:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLAssetPartial<T extends "
},
{
"kind": "Reference",
"text": "TLAsset",
"canonicalReference": "@tldraw/tlschema!TLAsset:type"
},
{
"kind": "Content",
"text": " = "
},
{
"kind": "Reference",
"text": "TLAsset",
"canonicalReference": "@tldraw/tlschema!TLAsset:type"
},
{
"kind": "Content",
"text": "> = "
},
{
"kind": "Content",
"text": "T extends T ? {\n id: "
},
{
"kind": "Reference",
"text": "TLAssetId",
"canonicalReference": "@tldraw/tlschema!TLAssetId:type"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": ";\n meta?: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "Partial",
"canonicalReference": "!Partial:type"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<T['meta']>;\n props?: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "Partial",
"canonicalReference": "!Partial:type"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<T['props']>;\n type: T['type'];\n} & "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "Partial",
"canonicalReference": "!Partial:type"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "Omit",
"canonicalReference": "!Omit:type"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "<T, 'id' | 'meta' | 'props' | 'type'>> : never"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLAsset.ts",
"releaseTag": "Public",
"name": "TLAssetPartial",
"typeParameters": [
{
"typeParameterName": "T",
"constraintTokenRange": {
"startIndex": 1,
"endIndex": 2
},
"defaultTypeTokenRange": {
"startIndex": 3,
"endIndex": 4
}
}
],
"typeTokenRange": {
"startIndex": 5,
"endIndex": 16
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLAssetShape:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLAssetShape = "
},
{
"kind": "Reference",
"text": "Extract",
"canonicalReference": "!Extract:type"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLShape",
"canonicalReference": "@tldraw/tlschema!TLShape:type"
},
{
"kind": "Content",
"text": ", {\n props: {\n assetId: "
},
{
"kind": "Reference",
"text": "TLAssetId",
"canonicalReference": "@tldraw/tlschema!TLAssetId:type"
},
{
"kind": "Content",
"text": ";\n };\n}>"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLAsset.ts",
"releaseTag": "Public",
"name": "TLAssetShape",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 7
}
},
{
"kind": "Interface",
"canonicalReference": "@tldraw/tlschema!TLBaseAsset:interface",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export interface TLBaseAsset<Type extends "
},
{
"kind": "Content",
"text": "string"
},
{
"kind": "Content",
"text": ", Props> extends "
},
{
"kind": "Reference",
"text": "BaseRecord",
"canonicalReference": "@tldraw/store!BaseRecord:interface"
},
{
"kind": "Content",
"text": "<'asset', "
},
{
"kind": "Reference",
"text": "TLAssetId",
"canonicalReference": "@tldraw/tlschema!TLAssetId:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": " "
}
],
"fileUrlPath": "packages/tlschema/src/assets/TLBaseAsset.ts",
"releaseTag": "Public",
"typeParameters": [
{
"typeParameterName": "Type",
"constraintTokenRange": {
"startIndex": 1,
"endIndex": 2
},
"defaultTypeTokenRange": {
"startIndex": 0,
"endIndex": 0
}
},
{
"typeParameterName": "Props",
"constraintTokenRange": {
"startIndex": 0,
"endIndex": 0
},
"defaultTypeTokenRange": {
"startIndex": 0,
"endIndex": 0
}
}
],
"name": "TLBaseAsset",
"preserveMemberOrder": false,
"members": [
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLBaseAsset#meta:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "meta: "
},
{
"kind": "Reference",
"text": "JsonObject",
"canonicalReference": "@tldraw/utils!JsonObject:type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "meta",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLBaseAsset#props:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "props: "
},
{
"kind": "Content",
"text": "Props"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "props",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLBaseAsset#type:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "type: "
},
{
"kind": "Content",
"text": "Type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "type",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
}
],
"extendsTokenRanges": [
{
"startIndex": 3,
"endIndex": 7
}
]
},
{
"kind": "Interface",
"canonicalReference": "@tldraw/tlschema!TLBaseShape:interface",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export interface TLBaseShape<Type extends "
},
{
"kind": "Content",
"text": "string"
},
{
"kind": "Content",
"text": ", Props extends "
},
{
"kind": "Content",
"text": "object"
},
{
"kind": "Content",
"text": "> extends "
},
{
"kind": "Reference",
"text": "BaseRecord",
"canonicalReference": "@tldraw/store!BaseRecord:interface"
},
{
"kind": "Content",
"text": "<'shape', "
},
{
"kind": "Reference",
"text": "TLShapeId",
"canonicalReference": "@tldraw/tlschema!TLShapeId:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": " "
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLBaseShape.ts",
"releaseTag": "Public",
"typeParameters": [
{
"typeParameterName": "Type",
"constraintTokenRange": {
"startIndex": 1,
"endIndex": 2
},
"defaultTypeTokenRange": {
"startIndex": 0,
"endIndex": 0
}
},
{
"typeParameterName": "Props",
"constraintTokenRange": {
"startIndex": 3,
"endIndex": 4
},
"defaultTypeTokenRange": {
"startIndex": 0,
"endIndex": 0
}
}
],
"name": "TLBaseShape",
"preserveMemberOrder": false,
"members": [
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLBaseShape#index:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "index: "
},
{
[Snapping 1/5] Validation & strict types for fractional indexes (#2827) Currently, we type our fractional index keys as `string` and don't have any validation for them. I'm touching some of this code for my work on line handles and wanted to change that: - fractional indexes are now `IndexKey`s, not `string`s. `IndexKey`s have a brand property so can't be used interchangeably with strings (like our IDs) - There's a new `T.indexKey` validator which we can use in our validations to make sure we don't end up with nonsense keys. This PR is part of a series - please don't merge it until the things before it have landed! 1. #2827 (you are here) 2. #2831 3. #2793 4. #2841 5. #2845 ### Change Type - [x] `patch` — Bug fix ### Test Plan 1. Mostly relying on unit & end to end tests here - no user facing changes. - [x] Unit Tests
2024-02-14 17:53:30 +00:00
"kind": "Reference",
"text": "IndexKey",
"canonicalReference": "@tldraw/utils!IndexKey:type"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "index",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLBaseShape#isLocked:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "isLocked: "
},
{
"kind": "Content",
"text": "boolean"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "isLocked",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLBaseShape#meta:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "meta: "
},
{
"kind": "Reference",
"text": "JsonObject",
"canonicalReference": "@tldraw/utils!JsonObject:type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "meta",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLBaseShape#opacity:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "opacity: "
},
{
"kind": "Reference",
"text": "TLOpacityType",
"canonicalReference": "@tldraw/tlschema!TLOpacityType:type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "opacity",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLBaseShape#parentId:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "parentId: "
},
{
"kind": "Reference",
"text": "TLParentId",
"canonicalReference": "@tldraw/tlschema!TLParentId:type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "parentId",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLBaseShape#props:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "props: "
},
{
"kind": "Content",
"text": "Props"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "props",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLBaseShape#rotation:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "rotation: "
},
{
"kind": "Content",
"text": "number"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "rotation",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLBaseShape#type:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "type: "
},
{
"kind": "Content",
"text": "Type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "type",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLBaseShape#x:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "x: "
},
{
"kind": "Content",
"text": "number"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "x",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLBaseShape#y:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "y: "
},
{
"kind": "Content",
"text": "number"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "y",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
}
],
"extendsTokenRanges": [
{
"startIndex": 5,
"endIndex": 9
}
]
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLBookmarkAsset:type",
"docComment": "/**\n * An asset used for URL bookmarks, used by the TLBookmarkShape.\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLBookmarkAsset = "
},
{
"kind": "Reference",
"text": "TLBaseAsset",
"canonicalReference": "@tldraw/tlschema!TLBaseAsset:interface"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<'bookmark', {\n description: string;\n image: string;\n src: null | string;\n title: string;\n}>"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/assets/TLBookmarkAsset.ts",
"releaseTag": "Public",
"name": "TLBookmarkAsset",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 3
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLBookmarkShape:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLBookmarkShape = "
},
{
"kind": "Reference",
"text": "TLBaseShape",
"canonicalReference": "@tldraw/tlschema!TLBaseShape:interface"
},
{
"kind": "Content",
"text": "<'bookmark', "
},
{
"kind": "Reference",
"text": "TLBookmarkShapeProps",
"canonicalReference": "@tldraw/tlschema!~TLBookmarkShapeProps:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLBookmarkShape.ts",
"releaseTag": "Public",
"name": "TLBookmarkShape",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "Interface",
"canonicalReference": "@tldraw/tlschema!TLCamera:interface",
"docComment": "/**\n * A camera record.\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export interface TLCamera extends "
},
{
"kind": "Reference",
"text": "BaseRecord",
"canonicalReference": "@tldraw/store!BaseRecord:interface"
},
{
"kind": "Content",
"text": "<'camera', "
},
{
"kind": "Reference",
"text": "TLCameraId",
"canonicalReference": "@tldraw/tlschema!TLCameraId:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": " "
}
],
"fileUrlPath": "packages/tlschema/src/records/TLCamera.ts",
"releaseTag": "Public",
"name": "TLCamera",
"preserveMemberOrder": false,
"members": [
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLCamera#meta:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "meta: "
},
{
"kind": "Reference",
"text": "JsonObject",
"canonicalReference": "@tldraw/utils!JsonObject:type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "meta",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLCamera#x:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "x: "
},
{
"kind": "Content",
"text": "number"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "x",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLCamera#y:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "y: "
},
{
"kind": "Content",
"text": "number"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "y",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLCamera#z:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "z: "
},
{
"kind": "Content",
"text": "number"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "z",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
}
],
"extendsTokenRanges": [
{
"startIndex": 1,
"endIndex": 5
}
]
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLCameraId:type",
"docComment": "/**\n * The id of a camera record.\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLCameraId = "
},
{
"kind": "Reference",
"text": "RecordId",
"canonicalReference": "@tldraw/store!RecordId:type"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLCamera",
"canonicalReference": "@tldraw/tlschema!TLCamera:interface"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLCamera.ts",
"releaseTag": "Public",
"name": "TLCameraId",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLCanvasUiColor:type",
"docComment": "/**\n * A type for the colors used by tldraw's default shapes.\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLCanvasUiColor = "
},
{
"kind": "Reference",
"text": "SetValue",
"canonicalReference": "@tldraw/tlschema!~SetValue:type"
},
{
"kind": "Content",
"text": "<typeof "
},
{
"kind": "Reference",
"text": "TL_CANVAS_UI_COLOR_TYPES",
"canonicalReference": "@tldraw/tlschema!TL_CANVAS_UI_COLOR_TYPES:var"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/misc/TLColor.ts",
"releaseTag": "Public",
"name": "TLCanvasUiColor",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "Interface",
"canonicalReference": "@tldraw/tlschema!TLCursor:interface",
"docComment": "/**\n * A cursor used by tldraw.\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export interface TLCursor "
}
],
"fileUrlPath": "packages/tlschema/src/misc/TLCursor.ts",
"releaseTag": "Public",
"name": "TLCursor",
"preserveMemberOrder": false,
"members": [
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLCursor#rotation:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "rotation: "
},
{
"kind": "Content",
"text": "number"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "rotation",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLCursor#type:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "type: "
},
{
"kind": "Reference",
"text": "TLCursorType",
"canonicalReference": "@tldraw/tlschema!TLCursorType:type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "type",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
}
],
"extendsTokenRanges": []
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLCursorType:type",
"docComment": "/**\n * A type for the cursor types used by tldraw's default shapes.\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLCursorType = "
},
{
"kind": "Reference",
"text": "SetValue",
"canonicalReference": "@tldraw/tlschema!~SetValue:type"
},
{
"kind": "Content",
"text": "<typeof "
},
{
"kind": "Reference",
"text": "TL_CURSOR_TYPES",
"canonicalReference": "@tldraw/tlschema!~TL_CURSOR_TYPES:var"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/misc/TLCursor.ts",
"releaseTag": "Public",
"name": "TLCursorType",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLDefaultColorStyle:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLDefaultColorStyle = "
},
{
"kind": "Reference",
"text": "T.TypeOf",
"canonicalReference": "@tldraw/validate!TypeOf:type"
},
{
"kind": "Content",
"text": "<typeof "
},
{
"kind": "Reference",
"text": "DefaultColorStyle",
"canonicalReference": "@tldraw/tlschema!DefaultColorStyle:var"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/styles/TLColorStyle.ts",
"releaseTag": "Public",
"name": "TLDefaultColorStyle",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLDefaultColorTheme:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLDefaultColorTheme = "
},
{
"kind": "Reference",
"text": "Expand",
"canonicalReference": "@tldraw/utils!Expand:type"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<{\n background: string;\n id: 'dark' | 'light';\n solid: string;\n text: string;\n} & "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "Record",
"canonicalReference": "!Record:type"
},
{
"kind": "Content",
"text": "<(typeof "
},
{
"kind": "Reference",
"text": "colors",
"canonicalReference": "@tldraw/tlschema!~colors:var"
},
{
"kind": "Content",
"text": ")[number], "
},
{
"kind": "Reference",
"text": "TLDefaultColorThemeColor",
"canonicalReference": "@tldraw/tlschema!TLDefaultColorThemeColor:type"
},
{
"kind": "Content",
"text": ">>"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/styles/TLColorStyle.ts",
"releaseTag": "Public",
"name": "TLDefaultColorTheme",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 9
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLDefaultColorThemeColor:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLDefaultColorThemeColor = "
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "{\n highlight: {\n p3: string;\n srgb: string;\n };\n note: {\n fill: string;\n text: string;\n };\n pattern: string;\n semi: string;\n solid: string;\n}"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/styles/TLColorStyle.ts",
"releaseTag": "Public",
"name": "TLDefaultColorThemeColor",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLDefaultDashStyle:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLDefaultDashStyle = "
},
{
"kind": "Reference",
"text": "T.TypeOf",
"canonicalReference": "@tldraw/validate!TypeOf:type"
},
{
"kind": "Content",
"text": "<typeof "
},
{
"kind": "Reference",
"text": "DefaultDashStyle",
"canonicalReference": "@tldraw/tlschema!DefaultDashStyle:var"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/styles/TLDashStyle.ts",
"releaseTag": "Public",
"name": "TLDefaultDashStyle",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLDefaultFillStyle:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLDefaultFillStyle = "
},
{
"kind": "Reference",
"text": "T.TypeOf",
"canonicalReference": "@tldraw/validate!TypeOf:type"
},
{
"kind": "Content",
"text": "<typeof "
},
{
"kind": "Reference",
"text": "DefaultFillStyle",
"canonicalReference": "@tldraw/tlschema!DefaultFillStyle:var"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/styles/TLFillStyle.ts",
"releaseTag": "Public",
"name": "TLDefaultFillStyle",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLDefaultFontStyle:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLDefaultFontStyle = "
},
{
"kind": "Reference",
"text": "T.TypeOf",
"canonicalReference": "@tldraw/validate!TypeOf:type"
},
{
"kind": "Content",
"text": "<typeof "
},
{
"kind": "Reference",
"text": "DefaultFontStyle",
"canonicalReference": "@tldraw/tlschema!DefaultFontStyle:var"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/styles/TLFontStyle.ts",
"releaseTag": "Public",
"name": "TLDefaultFontStyle",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLDefaultHorizontalAlignStyle:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLDefaultHorizontalAlignStyle = "
},
{
"kind": "Reference",
"text": "T.TypeOf",
"canonicalReference": "@tldraw/validate!TypeOf:type"
},
{
"kind": "Content",
"text": "<typeof "
},
{
"kind": "Reference",
"text": "DefaultHorizontalAlignStyle",
"canonicalReference": "@tldraw/tlschema!DefaultHorizontalAlignStyle:var"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/styles/TLHorizontalAlignStyle.ts",
"releaseTag": "Public",
"name": "TLDefaultHorizontalAlignStyle",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLDefaultShape:type",
"docComment": "/**\n * The default set of shapes that are available in the editor.\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLDefaultShape = "
},
{
"kind": "Reference",
"text": "TLArrowShape",
"canonicalReference": "@tldraw/tlschema!TLArrowShape:type"
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
"text": "TLBookmarkShape",
"canonicalReference": "@tldraw/tlschema!TLBookmarkShape:type"
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
"text": "TLDrawShape",
"canonicalReference": "@tldraw/tlschema!TLDrawShape:type"
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
"text": "TLEmbedShape",
"canonicalReference": "@tldraw/tlschema!TLEmbedShape:type"
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
"text": "TLFrameShape",
"canonicalReference": "@tldraw/tlschema!TLFrameShape:type"
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
"text": "TLGeoShape",
"canonicalReference": "@tldraw/tlschema!TLGeoShape:type"
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
"text": "TLGroupShape",
"canonicalReference": "@tldraw/tlschema!TLGroupShape:type"
},
{
"kind": "Content",
"text": " | "
},
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
{
"kind": "Reference",
"text": "TLHighlightShape",
"canonicalReference": "@tldraw/tlschema!TLHighlightShape:type"
},
{
"kind": "Content",
"text": " | "
},
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
{
"kind": "Reference",
"text": "TLImageShape",
"canonicalReference": "@tldraw/tlschema!TLImageShape:type"
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
"text": "TLLineShape",
"canonicalReference": "@tldraw/tlschema!TLLineShape:type"
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
"text": "TLNoteShape",
"canonicalReference": "@tldraw/tlschema!TLNoteShape:type"
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
"text": "TLTextShape",
"canonicalReference": "@tldraw/tlschema!TLTextShape:type"
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
"text": "TLVideoShape",
"canonicalReference": "@tldraw/tlschema!TLVideoShape:type"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLShape.ts",
"releaseTag": "Public",
"name": "TLDefaultShape",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 26
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLDefaultSizeStyle:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLDefaultSizeStyle = "
},
{
"kind": "Reference",
"text": "T.TypeOf",
"canonicalReference": "@tldraw/validate!TypeOf:type"
},
{
"kind": "Content",
"text": "<typeof "
},
{
"kind": "Reference",
"text": "DefaultSizeStyle",
"canonicalReference": "@tldraw/tlschema!DefaultSizeStyle:var"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/styles/TLSizeStyle.ts",
"releaseTag": "Public",
"name": "TLDefaultSizeStyle",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLDefaultVerticalAlignStyle:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLDefaultVerticalAlignStyle = "
},
{
"kind": "Reference",
"text": "T.TypeOf",
"canonicalReference": "@tldraw/validate!TypeOf:type"
},
{
"kind": "Content",
"text": "<typeof "
},
{
"kind": "Reference",
"text": "DefaultVerticalAlignStyle",
"canonicalReference": "@tldraw/tlschema!DefaultVerticalAlignStyle:var"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/styles/TLVerticalAlignStyle.ts",
"releaseTag": "Public",
"name": "TLDefaultVerticalAlignStyle",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!TLDOCUMENT_ID:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "TLDOCUMENT_ID: "
},
{
"kind": "Reference",
"text": "RecordId",
"canonicalReference": "@tldraw/store!RecordId:type"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLDocument",
"canonicalReference": "@tldraw/tlschema!TLDocument:interface"
},
{
"kind": "Content",
"text": ">"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLDocument.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "TLDOCUMENT_ID",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "Interface",
"canonicalReference": "@tldraw/tlschema!TLDocument:interface",
"docComment": "/**\n * TLDocument\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export interface TLDocument extends "
},
{
"kind": "Reference",
"text": "BaseRecord",
"canonicalReference": "@tldraw/store!BaseRecord:interface"
},
{
"kind": "Content",
"text": "<'document', "
},
{
"kind": "Reference",
"text": "RecordId",
"canonicalReference": "@tldraw/store!RecordId:type"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLDocument",
"canonicalReference": "@tldraw/tlschema!TLDocument:interface"
},
{
"kind": "Content",
"text": ">>"
},
{
"kind": "Content",
"text": " "
}
],
"fileUrlPath": "packages/tlschema/src/records/TLDocument.ts",
"releaseTag": "Public",
"name": "TLDocument",
"preserveMemberOrder": false,
"members": [
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLDocument#gridSize:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "gridSize: "
},
{
"kind": "Content",
"text": "number"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "gridSize",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLDocument#meta:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "meta: "
},
{
"kind": "Reference",
"text": "JsonObject",
"canonicalReference": "@tldraw/utils!JsonObject:type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "meta",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLDocument#name:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "name: "
},
{
"kind": "Content",
"text": "string"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "name",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
}
],
"extendsTokenRanges": [
{
"startIndex": 1,
"endIndex": 7
}
]
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLDrawShape:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLDrawShape = "
},
{
"kind": "Reference",
"text": "TLBaseShape",
"canonicalReference": "@tldraw/tlschema!TLBaseShape:interface"
},
{
"kind": "Content",
"text": "<'draw', "
},
{
"kind": "Reference",
"text": "TLDrawShapeProps",
"canonicalReference": "@tldraw/tlschema!~TLDrawShapeProps:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLDrawShape.ts",
"releaseTag": "Public",
"name": "TLDrawShape",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLDrawShapeSegment:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLDrawShapeSegment = "
},
{
"kind": "Reference",
"text": "T.TypeOf",
"canonicalReference": "@tldraw/validate!TypeOf:type"
},
{
"kind": "Content",
"text": "<typeof "
},
{
"kind": "Reference",
"text": "DrawShapeSegment",
"canonicalReference": "@tldraw/tlschema!~DrawShapeSegment:var"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLDrawShape.ts",
"releaseTag": "Public",
"name": "TLDrawShapeSegment",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLEmbedShape:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLEmbedShape = "
},
{
"kind": "Reference",
"text": "TLBaseShape",
"canonicalReference": "@tldraw/tlschema!TLBaseShape:interface"
},
{
"kind": "Content",
"text": "<'embed', "
},
{
"kind": "Reference",
"text": "TLEmbedShapeProps",
"canonicalReference": "@tldraw/tlschema!~TLEmbedShapeProps:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLEmbedShape.ts",
"releaseTag": "Public",
"name": "TLEmbedShape",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLEmbedShapePermissions:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLEmbedShapePermissions = "
},
{
"kind": "Content",
"text": "{\n [K in keyof typeof "
},
{
"kind": "Reference",
"text": "embedShapePermissionDefaults",
"canonicalReference": "@tldraw/tlschema!embedShapePermissionDefaults:var"
},
{
"kind": "Content",
"text": "]?: boolean;\n}"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLEmbedShape.ts",
"releaseTag": "Public",
"name": "TLEmbedShapePermissions",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 4
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLFrameShape:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLFrameShape = "
},
{
"kind": "Reference",
"text": "TLBaseShape",
"canonicalReference": "@tldraw/tlschema!TLBaseShape:interface"
},
{
"kind": "Content",
"text": "<'frame', "
},
{
"kind": "Reference",
"text": "TLFrameShapeProps",
"canonicalReference": "@tldraw/tlschema!~TLFrameShapeProps:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLFrameShape.ts",
"releaseTag": "Public",
"name": "TLFrameShape",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLGeoShape:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLGeoShape = "
},
{
"kind": "Reference",
"text": "TLBaseShape",
"canonicalReference": "@tldraw/tlschema!TLBaseShape:interface"
},
{
"kind": "Content",
"text": "<'geo', "
},
{
"kind": "Reference",
"text": "TLGeoShapeProps",
"canonicalReference": "@tldraw/tlschema!~TLGeoShapeProps:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLGeoShape.ts",
"releaseTag": "Public",
"name": "TLGeoShape",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLGroupShape:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLGroupShape = "
},
{
"kind": "Reference",
"text": "TLBaseShape",
"canonicalReference": "@tldraw/tlschema!TLBaseShape:interface"
},
{
"kind": "Content",
"text": "<'group', "
},
{
"kind": "Reference",
"text": "TLGroupShapeProps",
"canonicalReference": "@tldraw/tlschema!~TLGroupShapeProps:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLGroupShape.ts",
"releaseTag": "Public",
"name": "TLGroupShape",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "Interface",
"canonicalReference": "@tldraw/tlschema!TLHandle:interface",
"docComment": "/**\n * A base interface for a shape's handles.\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export interface TLHandle "
}
],
"fileUrlPath": "packages/tlschema/src/misc/TLHandle.ts",
"releaseTag": "Public",
"name": "TLHandle",
"preserveMemberOrder": false,
"members": [
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLHandle#canBind:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "canBind?: "
},
{
"kind": "Content",
"text": "boolean"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": true,
"releaseTag": "Public",
"name": "canBind",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLHandle#canSnap:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "canSnap?: "
},
{
"kind": "Content",
"text": "boolean"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": true,
"releaseTag": "Public",
"name": "canSnap",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLHandle#id:member",
"docComment": "/**\n * A unique identifier for the handle.\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "id: "
},
{
"kind": "Content",
"text": "string"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "id",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLHandle#index:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "index: "
},
{
[Snapping 1/5] Validation & strict types for fractional indexes (#2827) Currently, we type our fractional index keys as `string` and don't have any validation for them. I'm touching some of this code for my work on line handles and wanted to change that: - fractional indexes are now `IndexKey`s, not `string`s. `IndexKey`s have a brand property so can't be used interchangeably with strings (like our IDs) - There's a new `T.indexKey` validator which we can use in our validations to make sure we don't end up with nonsense keys. This PR is part of a series - please don't merge it until the things before it have landed! 1. #2827 (you are here) 2. #2831 3. #2793 4. #2841 5. #2845 ### Change Type - [x] `patch` — Bug fix ### Test Plan 1. Mostly relying on unit & end to end tests here - no user facing changes. - [x] Unit Tests
2024-02-14 17:53:30 +00:00
"kind": "Reference",
"text": "IndexKey",
"canonicalReference": "@tldraw/utils!IndexKey:type"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "index",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLHandle#type:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "type: "
},
{
"kind": "Reference",
"text": "TLHandleType",
"canonicalReference": "@tldraw/tlschema!TLHandleType:type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "type",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLHandle#x:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "x: "
},
{
"kind": "Content",
"text": "number"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "x",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLHandle#y:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "y: "
},
{
"kind": "Content",
"text": "number"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "y",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
}
],
"extendsTokenRanges": []
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLHandleType:type",
"docComment": "/**\n * A type for the handle types used by tldraw's default shapes.\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLHandleType = "
},
{
"kind": "Reference",
"text": "SetValue",
"canonicalReference": "@tldraw/tlschema!~SetValue:type"
},
{
"kind": "Content",
"text": "<typeof "
},
{
"kind": "Reference",
"text": "TL_HANDLE_TYPES",
"canonicalReference": "@tldraw/tlschema!~TL_HANDLE_TYPES:var"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/misc/TLHandle.ts",
"releaseTag": "Public",
"name": "TLHandleType",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLHighlightShape:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLHighlightShape = "
},
{
"kind": "Reference",
"text": "TLBaseShape",
"canonicalReference": "@tldraw/tlschema!TLBaseShape:interface"
},
{
"kind": "Content",
"text": "<'highlight', "
},
{
"kind": "Reference",
"text": "TLHighlightShapeProps",
"canonicalReference": "@tldraw/tlschema!~TLHighlightShapeProps:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLHighlightShape.ts",
"releaseTag": "Public",
"name": "TLHighlightShape",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLImageAsset:type",
"docComment": "/**\n * An asset for images such as PNGs and JPEGs, used by the TLImageShape.\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLImageAsset = "
},
{
"kind": "Reference",
"text": "TLBaseAsset",
"canonicalReference": "@tldraw/tlschema!TLBaseAsset:interface"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<'image', {\n h: number;\n isAnimated: boolean;\n mimeType: null | string;\n name: string;\n src: null | string;\n w: number;\n}>"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/assets/TLImageAsset.ts",
"releaseTag": "Public",
"name": "TLImageAsset",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 3
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLImageShape:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLImageShape = "
},
{
"kind": "Reference",
"text": "TLBaseShape",
"canonicalReference": "@tldraw/tlschema!TLBaseShape:interface"
},
{
"kind": "Content",
"text": "<'image', "
},
{
"kind": "Reference",
"text": "TLImageShapeProps",
"canonicalReference": "@tldraw/tlschema!TLImageShapeProps:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLImageShape.ts",
"releaseTag": "Public",
"name": "TLImageShape",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLImageShapeCrop:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLImageShapeCrop = "
},
{
"kind": "Reference",
"text": "T.TypeOf",
"canonicalReference": "@tldraw/validate!TypeOf:type"
},
{
"kind": "Content",
"text": "<typeof "
},
{
"kind": "Reference",
"text": "ImageShapeCrop",
"canonicalReference": "@tldraw/tlschema!~ImageShapeCrop:var"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLImageShape.ts",
"releaseTag": "Public",
"name": "TLImageShapeCrop",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLImageShapeProps:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLImageShapeProps = "
},
{
"kind": "Reference",
"text": "ShapePropsType",
Stickies: release candidate (#3249) This PR is the target for the stickies PRs that are moving forward. It should collect changes. - [x] New icon - [x] Improved shadows - [x] Shadow LOD - [x] New colors / theme options - [x] Shrink text size to avoid word breaks on the x axis - [x] Hide indicator whilst typing (reverted) - [x] Adjacent note positions - [x] buttons / clone handles - [x] position helpers for creating / translating (pits) - [x] keyboard shortcuts: (Tab, Shift+tab (RTL aware), Cmd-Enter, Shift+Cmd+enter) - [x] multiple shape translating - [x] Text editing - [x] Edit on type (feature flagged) - [x] click goes in correct place - [x] Notes as parents (reverted) - [x] Update colors - [x] Update SVG appearance ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `feature` — New feature ### Test Plan Todo: fold in test plans for child PRs ### Unit tests: - [ ] Shrink text size to avoid word breaks on the x axis - [x] Adjacent notes - [x] buttons (clone handles) - [x] position helpers (pits) - [x] keyboard shortcuts: (Tab, Shift+tab (RTL aware), Cmd-Enter, Shift+Cmd+enter) - [ ] Text editing - [ ] Edit on type - [ ] click goes in correct place ### Release Notes - Improves sticky notes (see list) --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com> Co-authored-by: alex <alex@dytry.ch> Co-authored-by: Mitja Bezenšek <mitja.bezensek@gmail.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Lu[ke] Wilson <l2wilson94@gmail.com> Co-authored-by: huppy-bot[bot] <128400622+huppy-bot[bot]@users.noreply.github.com>
2024-04-14 18:40:02 +00:00
"canonicalReference": "@tldraw/tlschema!ShapePropsType:type"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": "<typeof "
},
{
"kind": "Reference",
"text": "imageShapeProps",
"canonicalReference": "@tldraw/tlschema!imageShapeProps:var"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLImageShape.ts",
"releaseTag": "Public",
"name": "TLImageShapeProps",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!TLINSTANCE_ID:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "TLINSTANCE_ID: "
},
{
"kind": "Reference",
"text": "TLInstanceId",
"canonicalReference": "@tldraw/tlschema!TLInstanceId:type"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLInstance.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "TLINSTANCE_ID",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "Interface",
"canonicalReference": "@tldraw/tlschema!TLInstance:interface",
"docComment": "/**\n * TLInstance\n *\n * State that is particular to a single browser tab\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export interface TLInstance extends "
},
{
"kind": "Reference",
"text": "BaseRecord",
"canonicalReference": "@tldraw/store!BaseRecord:interface"
},
{
"kind": "Content",
"text": "<'instance', "
},
{
"kind": "Reference",
"text": "TLInstanceId",
"canonicalReference": "@tldraw/tlschema!TLInstanceId:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": " "
}
],
"fileUrlPath": "packages/tlschema/src/records/TLInstance.ts",
"releaseTag": "Public",
"name": "TLInstance",
"preserveMemberOrder": false,
"members": [
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#brush:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "brush: "
},
{
"kind": "Reference",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"text": "BoxModel",
"canonicalReference": "@tldraw/tlschema!BoxModel:interface"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": " | null"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "brush",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 3
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#canMoveCamera:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "canMoveCamera: "
},
{
"kind": "Content",
"text": "boolean"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "canMoveCamera",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#chatMessage:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "chatMessage: "
},
{
"kind": "Content",
"text": "string"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "chatMessage",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#currentPageId:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "currentPageId: "
},
{
"kind": "Reference",
"text": "TLPageId",
"canonicalReference": "@tldraw/tlschema!TLPageId:type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "currentPageId",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#cursor:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "cursor: "
},
{
"kind": "Reference",
"text": "TLCursor",
"canonicalReference": "@tldraw/tlschema!TLCursor:interface"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "cursor",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#devicePixelRatio:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "devicePixelRatio: "
},
{
"kind": "Content",
"text": "number"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "devicePixelRatio",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
Improved duplication (#2480) Improves duplication. It will now remember the offset and shapes of your `alt + drag` duplication and use that if you use the duplicate action immediately after this. ![duplicate](https://github.com/tldraw/tldraw/assets/2523721/6fbfd455-d179-4eae-8aba-399b0781f633) Fixes https://github.com/tldraw/tldraw/issues/2264 ### 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 ### 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. --------- Co-authored-by: Taha <98838967+Taha-Hassan-Git@users.noreply.github.com> Co-authored-by: David Sheldrick <d.j.sheldrick@gmail.com> Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-01-26 14:54:52 +00:00
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#duplicateProps:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "duplicateProps: "
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "{\n offset: {\n x: number;\n y: number;\n };\n shapeIds: "
Improved duplication (#2480) Improves duplication. It will now remember the offset and shapes of your `alt + drag` duplication and use that if you use the duplicate action immediately after this. ![duplicate](https://github.com/tldraw/tldraw/assets/2523721/6fbfd455-d179-4eae-8aba-399b0781f633) Fixes https://github.com/tldraw/tldraw/issues/2264 ### 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 ### 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. --------- Co-authored-by: Taha <98838967+Taha-Hassan-Git@users.noreply.github.com> Co-authored-by: David Sheldrick <d.j.sheldrick@gmail.com> Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-01-26 14:54:52 +00:00
},
{
"kind": "Reference",
"text": "TLShapeId",
"canonicalReference": "@tldraw/tlschema!TLShapeId:type"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "[];\n } | null"
Improved duplication (#2480) Improves duplication. It will now remember the offset and shapes of your `alt + drag` duplication and use that if you use the duplicate action immediately after this. ![duplicate](https://github.com/tldraw/tldraw/assets/2523721/6fbfd455-d179-4eae-8aba-399b0781f633) Fixes https://github.com/tldraw/tldraw/issues/2264 ### 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 ### 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. --------- Co-authored-by: Taha <98838967+Taha-Hassan-Git@users.noreply.github.com> Co-authored-by: David Sheldrick <d.j.sheldrick@gmail.com> Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-01-26 14:54:52 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "duplicateProps",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 4
}
},
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#exportBackground:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "exportBackground: "
},
{
"kind": "Content",
"text": "boolean"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "exportBackground",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#followingUserId:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "followingUserId: "
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "null | string"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "followingUserId",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#highlightedUserIds:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "highlightedUserIds: "
},
{
"kind": "Content",
"text": "string[]"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "highlightedUserIds",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
[improvement] account for coarse pointers / insets in edge scrolling (#2401) This PR: - shrinks the distance for edge scrolling and insets the distance for coarse pointers - adds edge inset tracking ## Scroll distances Rather than increasing the distance, we move the "zero" in from the edges, so that the middle of a honkin' fat finger would be at "zero" when the edge of the finger is touching the edge of the screen. This is a bit more reliable than looking at just the component size. ## Inset tracking We now track whether a shape's edges are identical to the edges of the document body. When an edge is inset, we extend the edge scrolling distance outside of the component, so that dragging PAST the edge of the component will scroll. When an edge is NOT inset, we bring that distance into the component's bounds, so that dragging NEAR TO the edge will begin to scroll. ![image](https://github.com/tldraw/tldraw/assets/23072548/bb216c98-3dd0-4e2e-a635-4c4f339d5117) ![image](https://github.com/tldraw/tldraw/assets/23072548/75e83c81-1ca9-40a9-8edc-72851d3b1411) ![image](https://github.com/tldraw/tldraw/assets/23072548/6cda7bda-2935-4ded-821c-e7bf78833a1c) ### Change Type - [x] `minor` — New feature ### Test Plan 1. Use edge scrolling on mobile 2. Use edge scrolling on desktop 3. Use edge scrolling in the "scrolling example" - [x] Unit Tests ### Release Notes - Add `instanceState.insets` to track which edges of the component are inset from the edges of the document body. - Improve behavior around edge scrolling
2024-01-10 14:29:32 +00:00
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#insets:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "insets: "
},
{
"kind": "Content",
"text": "boolean[]"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "insets",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#isChangingStyle:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "isChangingStyle: "
},
{
"kind": "Content",
"text": "boolean"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "isChangingStyle",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#isChatting:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "isChatting: "
},
{
"kind": "Content",
"text": "boolean"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "isChatting",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#isCoarsePointer:member",
[fix] disable vertical edge resizing for text on mobile (#2456) This is a followup to PR #2347 which was addressing #2349. This makes sure that vertical resizing is disabled still for the text shapes because they get in the way of rotation. Fixes #2455 ### 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.
2024-01-12 09:40:42 +00:00
"docComment": "/**\n * This is whether the primary input mechanism includes a pointing device of limited accuracy, such as a finger on a touchscreen. See: https://developer.mozilla.org/en-US/docs/Web/CSS/\\@media/pointer\n */\n",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"excerptTokens": [
{
"kind": "Content",
"text": "isCoarsePointer: "
},
{
"kind": "Content",
"text": "boolean"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "isCoarsePointer",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#isDebugMode:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "isDebugMode: "
},
{
"kind": "Content",
"text": "boolean"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "isDebugMode",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#isFocused:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "isFocused: "
},
{
"kind": "Content",
"text": "boolean"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "isFocused",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#isFocusMode:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "isFocusMode: "
},
{
"kind": "Content",
"text": "boolean"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "isFocusMode",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#isGridMode:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "isGridMode: "
},
{
"kind": "Content",
"text": "boolean"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "isGridMode",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
Remove dot com ui styles [1/2] (#2039) This PR removes some ui styles that were only being used on tldraw.com ### Change Type - [x] `minor` — New feature
2023-10-09 07:11:34 +00:00
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#isHoveringCanvas:member",
"docComment": "/**\n * Will be null if the pointer doesn't support hovering (e.g. touch), but true or false otherwise\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "isHoveringCanvas: "
},
{
"kind": "Content",
"text": "boolean | null"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "isHoveringCanvas",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#isPenMode:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "isPenMode: "
},
{
"kind": "Content",
"text": "boolean"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "isPenMode",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#isReadonly:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "isReadonly: "
},
{
"kind": "Content",
"text": "boolean"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "isReadonly",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#isToolLocked:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "isToolLocked: "
},
{
"kind": "Content",
"text": "boolean"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "isToolLocked",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#meta:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "meta: "
},
{
"kind": "Reference",
"text": "JsonObject",
"canonicalReference": "@tldraw/utils!JsonObject:type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "meta",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#opacityForNextShape:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "opacityForNextShape: "
},
{
"kind": "Reference",
"text": "TLOpacityType",
"canonicalReference": "@tldraw/tlschema!TLOpacityType:type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "opacityForNextShape",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#openMenus:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "openMenus: "
},
{
"kind": "Content",
"text": "string[]"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "openMenus",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#screenBounds:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "screenBounds: "
},
{
"kind": "Reference",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"text": "BoxModel",
"canonicalReference": "@tldraw/tlschema!BoxModel:interface"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "screenBounds",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
[feature] multi-scribbles (#2125) This PR adds support for multiple scribbles at the same time. It prevents the sudden disappearance of existing scribbles when new ones are added. It simplifies the management of scribbles by moving the scribble manager to the editor. ![Kapture 2023-10-29 at 10 17 48](https://github.com/tldraw/tldraw/assets/23072548/23089047-6247-4714-bb79-c4972370140f) ### Change Type - [x] `minor` — New feature ### Test Plan 1. Use the eraser, scribble select, and laser pointer tools - [x] Unit Tests ### Release Notes - [feature] multi scribbles
2023-10-29 14:37:36 +00:00
"canonicalReference": "@tldraw/tlschema!TLInstance#scribbles:member",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
[feature] multi-scribbles (#2125) This PR adds support for multiple scribbles at the same time. It prevents the sudden disappearance of existing scribbles when new ones are added. It simplifies the management of scribbles by moving the scribble manager to the editor. ![Kapture 2023-10-29 at 10 17 48](https://github.com/tldraw/tldraw/assets/23072548/23089047-6247-4714-bb79-c4972370140f) ### Change Type - [x] `minor` — New feature ### Test Plan 1. Use the eraser, scribble select, and laser pointer tools - [x] Unit Tests ### Release Notes - [feature] multi scribbles
2023-10-29 14:37:36 +00:00
"text": "scribbles: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "TLScribble",
"canonicalReference": "@tldraw/tlschema!TLScribble:type"
},
[feature] multi-scribbles (#2125) This PR adds support for multiple scribbles at the same time. It prevents the sudden disappearance of existing scribbles when new ones are added. It simplifies the management of scribbles by moving the scribble manager to the editor. ![Kapture 2023-10-29 at 10 17 48](https://github.com/tldraw/tldraw/assets/23072548/23089047-6247-4714-bb79-c4972370140f) ### Change Type - [x] `minor` — New feature ### Test Plan 1. Use the eraser, scribble select, and laser pointer tools - [x] Unit Tests ### Release Notes - [feature] multi scribbles
2023-10-29 14:37:36 +00:00
{
"kind": "Content",
"text": "[]"
},
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
[feature] multi-scribbles (#2125) This PR adds support for multiple scribbles at the same time. It prevents the sudden disappearance of existing scribbles when new ones are added. It simplifies the management of scribbles by moving the scribble manager to the editor. ![Kapture 2023-10-29 at 10 17 48](https://github.com/tldraw/tldraw/assets/23072548/23089047-6247-4714-bb79-c4972370140f) ### Change Type - [x] `minor` — New feature ### Test Plan 1. Use the eraser, scribble select, and laser pointer tools - [x] Unit Tests ### Release Notes - [feature] multi scribbles
2023-10-29 14:37:36 +00:00
"name": "scribbles",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 3
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#stylesForNextShape:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "stylesForNextShape: "
},
{
"kind": "Reference",
"text": "Record",
"canonicalReference": "!Record:type"
},
{
"kind": "Content",
"text": "<string, unknown>"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "stylesForNextShape",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 3
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstance#zoomBrush:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "zoomBrush: "
},
{
"kind": "Reference",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"text": "BoxModel",
"canonicalReference": "@tldraw/tlschema!BoxModel:interface"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": " | null"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "zoomBrush",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 3
}
}
],
"extendsTokenRanges": [
{
"startIndex": 1,
"endIndex": 5
}
]
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLInstanceId:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLInstanceId = "
},
{
"kind": "Reference",
"text": "RecordId",
"canonicalReference": "@tldraw/store!RecordId:type"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLInstance",
"canonicalReference": "@tldraw/tlschema!TLInstance:interface"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLInstance.ts",
"releaseTag": "Public",
"name": "TLInstanceId",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "Interface",
"canonicalReference": "@tldraw/tlschema!TLInstancePageState:interface",
"docComment": "/**\n * TLInstancePageState\n *\n * State that is unique to a particular page of the document in a particular browser tab\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export interface TLInstancePageState extends "
},
{
"kind": "Reference",
"text": "BaseRecord",
"canonicalReference": "@tldraw/store!BaseRecord:interface"
},
{
"kind": "Content",
"text": "<'instance_page_state', "
},
{
"kind": "Reference",
"text": "TLInstancePageStateId",
"canonicalReference": "@tldraw/tlschema!~TLInstancePageStateId:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": " "
}
],
"fileUrlPath": "packages/tlschema/src/records/TLPageState.ts",
"releaseTag": "Public",
"name": "TLInstancePageState",
"preserveMemberOrder": false,
"members": [
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePageState#croppingShapeId:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "croppingShapeId: "
},
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
{
"kind": "Content",
"text": "null | "
},
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
{
"kind": "Reference",
"text": "TLShapeId",
"canonicalReference": "@tldraw/tlschema!TLShapeId:type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "croppingShapeId",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 3
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePageState#editingShapeId:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "editingShapeId: "
},
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
{
"kind": "Content",
"text": "null | "
},
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
{
"kind": "Reference",
"text": "TLShapeId",
"canonicalReference": "@tldraw/tlschema!TLShapeId:type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "editingShapeId",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 3
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePageState#erasingShapeIds:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "erasingShapeIds: "
},
{
"kind": "Reference",
"text": "TLShapeId",
"canonicalReference": "@tldraw/tlschema!TLShapeId:type"
},
{
"kind": "Content",
"text": "[]"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "erasingShapeIds",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 3
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePageState#focusedGroupId:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "focusedGroupId: "
},
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
{
"kind": "Content",
"text": "null | "
},
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
{
"kind": "Reference",
"text": "TLShapeId",
"canonicalReference": "@tldraw/tlschema!TLShapeId:type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "focusedGroupId",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 3
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePageState#hintingShapeIds:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "hintingShapeIds: "
},
{
"kind": "Reference",
"text": "TLShapeId",
"canonicalReference": "@tldraw/tlschema!TLShapeId:type"
},
{
"kind": "Content",
"text": "[]"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "hintingShapeIds",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 3
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePageState#hoveredShapeId:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "hoveredShapeId: "
},
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
{
"kind": "Content",
"text": "null | "
},
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
{
"kind": "Reference",
"text": "TLShapeId",
"canonicalReference": "@tldraw/tlschema!TLShapeId:type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "hoveredShapeId",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 3
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePageState#meta:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "meta: "
},
{
"kind": "Reference",
"text": "JsonObject",
"canonicalReference": "@tldraw/utils!JsonObject:type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "meta",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePageState#pageId:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "pageId: "
},
{
"kind": "Reference",
"text": "RecordId",
"canonicalReference": "@tldraw/store!RecordId:type"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLPage",
"canonicalReference": "@tldraw/tlschema!TLPage:interface"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "pageId",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePageState#selectedShapeIds:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "selectedShapeIds: "
},
{
"kind": "Reference",
"text": "TLShapeId",
"canonicalReference": "@tldraw/tlschema!TLShapeId:type"
},
{
"kind": "Content",
"text": "[]"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "selectedShapeIds",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 3
}
}
],
"extendsTokenRanges": [
{
"startIndex": 1,
"endIndex": 5
}
]
},
{
"kind": "Interface",
"canonicalReference": "@tldraw/tlschema!TLInstancePresence:interface",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export interface TLInstancePresence extends "
},
{
"kind": "Reference",
"text": "BaseRecord",
"canonicalReference": "@tldraw/store!BaseRecord:interface"
},
{
"kind": "Content",
"text": "<'instance_presence', "
},
{
"kind": "Reference",
"text": "TLInstancePresenceID",
"canonicalReference": "@tldraw/tlschema!~TLInstancePresenceID:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": " "
}
],
"fileUrlPath": "packages/tlschema/src/records/TLPresence.ts",
"releaseTag": "Public",
"name": "TLInstancePresence",
"preserveMemberOrder": false,
"members": [
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePresence#brush:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "brush: "
},
{
"kind": "Reference",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"text": "BoxModel",
"canonicalReference": "@tldraw/tlschema!BoxModel:interface"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": " | null"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "brush",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 3
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePresence#camera:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "camera: "
},
{
"kind": "Content",
"text": "{\n x: number;\n y: number;\n z: number;\n }"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "camera",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePresence#chatMessage:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "chatMessage: "
},
{
"kind": "Content",
"text": "string"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "chatMessage",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePresence#color:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "color: "
},
{
"kind": "Content",
"text": "string"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "color",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePresence#currentPageId:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "currentPageId: "
},
{
"kind": "Reference",
"text": "TLPageId",
"canonicalReference": "@tldraw/tlschema!TLPageId:type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "currentPageId",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePresence#cursor:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "cursor: "
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "{\n rotation: number;\n type: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "TLCursor",
"canonicalReference": "@tldraw/tlschema!TLCursor:interface"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "['type'];\n x: number;\n y: number;\n }"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "cursor",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 4
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePresence#followingUserId:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "followingUserId: "
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "null | string"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "followingUserId",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePresence#lastActivityTimestamp:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "lastActivityTimestamp: "
},
{
"kind": "Content",
"text": "number"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "lastActivityTimestamp",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePresence#meta:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "meta: "
},
{
"kind": "Reference",
"text": "JsonObject",
"canonicalReference": "@tldraw/utils!JsonObject:type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "meta",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePresence#screenBounds:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "screenBounds: "
},
{
"kind": "Reference",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"text": "BoxModel",
"canonicalReference": "@tldraw/tlschema!BoxModel:interface"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "screenBounds",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
[feature] multi-scribbles (#2125) This PR adds support for multiple scribbles at the same time. It prevents the sudden disappearance of existing scribbles when new ones are added. It simplifies the management of scribbles by moving the scribble manager to the editor. ![Kapture 2023-10-29 at 10 17 48](https://github.com/tldraw/tldraw/assets/23072548/23089047-6247-4714-bb79-c4972370140f) ### Change Type - [x] `minor` — New feature ### Test Plan 1. Use the eraser, scribble select, and laser pointer tools - [x] Unit Tests ### Release Notes - [feature] multi scribbles
2023-10-29 14:37:36 +00:00
"canonicalReference": "@tldraw/tlschema!TLInstancePresence#scribbles:member",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
[feature] multi-scribbles (#2125) This PR adds support for multiple scribbles at the same time. It prevents the sudden disappearance of existing scribbles when new ones are added. It simplifies the management of scribbles by moving the scribble manager to the editor. ![Kapture 2023-10-29 at 10 17 48](https://github.com/tldraw/tldraw/assets/23072548/23089047-6247-4714-bb79-c4972370140f) ### Change Type - [x] `minor` — New feature ### Test Plan 1. Use the eraser, scribble select, and laser pointer tools - [x] Unit Tests ### Release Notes - [feature] multi scribbles
2023-10-29 14:37:36 +00:00
"text": "scribbles: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "TLScribble",
"canonicalReference": "@tldraw/tlschema!TLScribble:type"
},
[feature] multi-scribbles (#2125) This PR adds support for multiple scribbles at the same time. It prevents the sudden disappearance of existing scribbles when new ones are added. It simplifies the management of scribbles by moving the scribble manager to the editor. ![Kapture 2023-10-29 at 10 17 48](https://github.com/tldraw/tldraw/assets/23072548/23089047-6247-4714-bb79-c4972370140f) ### Change Type - [x] `minor` — New feature ### Test Plan 1. Use the eraser, scribble select, and laser pointer tools - [x] Unit Tests ### Release Notes - [feature] multi scribbles
2023-10-29 14:37:36 +00:00
{
"kind": "Content",
"text": "[]"
},
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
[feature] multi-scribbles (#2125) This PR adds support for multiple scribbles at the same time. It prevents the sudden disappearance of existing scribbles when new ones are added. It simplifies the management of scribbles by moving the scribble manager to the editor. ![Kapture 2023-10-29 at 10 17 48](https://github.com/tldraw/tldraw/assets/23072548/23089047-6247-4714-bb79-c4972370140f) ### Change Type - [x] `minor` — New feature ### Test Plan 1. Use the eraser, scribble select, and laser pointer tools - [x] Unit Tests ### Release Notes - [feature] multi scribbles
2023-10-29 14:37:36 +00:00
"name": "scribbles",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 3
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePresence#selectedShapeIds:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "selectedShapeIds: "
},
{
"kind": "Reference",
"text": "TLShapeId",
"canonicalReference": "@tldraw/tlschema!TLShapeId:type"
},
{
"kind": "Content",
"text": "[]"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "selectedShapeIds",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 3
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePresence#userId:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "userId: "
},
{
"kind": "Content",
"text": "string"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "userId",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLInstancePresence#userName:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "userName: "
},
{
"kind": "Content",
"text": "string"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "userName",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
}
],
"extendsTokenRanges": [
{
"startIndex": 1,
"endIndex": 5
}
]
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLLanguage:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLLanguage = "
},
{
"kind": "Content",
"text": "(typeof "
},
{
"kind": "Reference",
"text": "LANGUAGES",
"canonicalReference": "@tldraw/tlschema!LANGUAGES:var"
},
{
"kind": "Content",
"text": ")[number]"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/translations/translations.ts",
"releaseTag": "Public",
"name": "TLLanguage",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 4
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLLineShape:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLLineShape = "
},
{
"kind": "Reference",
"text": "TLBaseShape",
"canonicalReference": "@tldraw/tlschema!TLBaseShape:interface"
},
{
"kind": "Content",
"text": "<'line', "
},
{
"kind": "Reference",
"text": "TLLineShapeProps",
"canonicalReference": "@tldraw/tlschema!~TLLineShapeProps:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLLineShape.ts",
"releaseTag": "Public",
"name": "TLLineShape",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLNoteShape:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLNoteShape = "
},
{
"kind": "Reference",
"text": "TLBaseShape",
"canonicalReference": "@tldraw/tlschema!TLBaseShape:interface"
},
{
"kind": "Content",
"text": "<'note', "
},
{
"kind": "Reference",
"text": "TLNoteShapeProps",
"canonicalReference": "@tldraw/tlschema!~TLNoteShapeProps:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLNoteShape.ts",
"releaseTag": "Public",
"name": "TLNoteShape",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLOpacityType:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLOpacityType = "
},
{
"kind": "Content",
"text": "number"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/misc/TLOpacity.ts",
"releaseTag": "Public",
"name": "TLOpacityType",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "Interface",
"canonicalReference": "@tldraw/tlschema!TLPage:interface",
"docComment": "/**\n * TLPage\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export interface TLPage extends "
},
{
"kind": "Reference",
"text": "BaseRecord",
"canonicalReference": "@tldraw/store!BaseRecord:interface"
},
{
"kind": "Content",
"text": "<'page', "
},
{
"kind": "Reference",
"text": "TLPageId",
"canonicalReference": "@tldraw/tlschema!TLPageId:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": " "
}
],
"fileUrlPath": "packages/tlschema/src/records/TLPage.ts",
"releaseTag": "Public",
"name": "TLPage",
"preserveMemberOrder": false,
"members": [
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLPage#index:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "index: "
},
{
[Snapping 1/5] Validation & strict types for fractional indexes (#2827) Currently, we type our fractional index keys as `string` and don't have any validation for them. I'm touching some of this code for my work on line handles and wanted to change that: - fractional indexes are now `IndexKey`s, not `string`s. `IndexKey`s have a brand property so can't be used interchangeably with strings (like our IDs) - There's a new `T.indexKey` validator which we can use in our validations to make sure we don't end up with nonsense keys. This PR is part of a series - please don't merge it until the things before it have landed! 1. #2827 (you are here) 2. #2831 3. #2793 4. #2841 5. #2845 ### Change Type - [x] `patch` — Bug fix ### Test Plan 1. Mostly relying on unit & end to end tests here - no user facing changes. - [x] Unit Tests
2024-02-14 17:53:30 +00:00
"kind": "Reference",
"text": "IndexKey",
"canonicalReference": "@tldraw/utils!IndexKey:type"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "index",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLPage#meta:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "meta: "
},
{
"kind": "Reference",
"text": "JsonObject",
"canonicalReference": "@tldraw/utils!JsonObject:type"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "meta",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
"canonicalReference": "@tldraw/tlschema!TLPage#name:member",
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "name: "
},
{
"kind": "Content",
"text": "string"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "name",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
}
],
"extendsTokenRanges": [
{
"startIndex": 1,
"endIndex": 5
}
]
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLPageId:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLPageId = "
},
{
"kind": "Reference",
"text": "RecordId",
"canonicalReference": "@tldraw/store!RecordId:type"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLPage",
"canonicalReference": "@tldraw/tlschema!TLPage:interface"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLPage.ts",
"releaseTag": "Public",
"name": "TLPageId",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLParentId:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLParentId = "
},
{
"kind": "Reference",
"text": "TLPageId",
"canonicalReference": "@tldraw/tlschema!TLPageId:type"
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
"text": "TLShapeId",
"canonicalReference": "@tldraw/tlschema!TLShapeId:type"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLShape.ts",
"releaseTag": "Public",
"name": "TLParentId",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 4
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!TLPOINTER_ID:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "TLPOINTER_ID: "
},
{
"kind": "Reference",
"text": "TLPointerId",
"canonicalReference": "@tldraw/tlschema!~TLPointerId:type"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLPointer.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "TLPOINTER_ID",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLRecord:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLRecord = "
},
{
"kind": "Reference",
"text": "TLAsset",
"canonicalReference": "@tldraw/tlschema!TLAsset:type"
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
"text": "TLCamera",
"canonicalReference": "@tldraw/tlschema!TLCamera:interface"
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
"text": "TLDocument",
"canonicalReference": "@tldraw/tlschema!TLDocument:interface"
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
"text": "TLInstance",
"canonicalReference": "@tldraw/tlschema!TLInstance:interface"
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
"text": "TLInstancePageState",
"canonicalReference": "@tldraw/tlschema!TLInstancePageState:interface"
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "TLInstancePresence",
"canonicalReference": "@tldraw/tlschema!TLInstancePresence:interface"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "TLPage",
"canonicalReference": "@tldraw/tlschema!TLPage:interface"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "TLPointer",
"canonicalReference": "@tldraw/tlschema!~TLPointer:interface"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "TLShape",
"canonicalReference": "@tldraw/tlschema!TLShape:type"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLRecord.ts",
"releaseTag": "Public",
"name": "TLRecord",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 18
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLSchema:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLSchema = "
},
{
"kind": "Reference",
"text": "StoreSchema",
"canonicalReference": "@tldraw/store!StoreSchema:class"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLRecord",
"canonicalReference": "@tldraw/tlschema!TLRecord:type"
},
{
"kind": "Content",
"text": ", "
},
{
"kind": "Reference",
"text": "TLStoreProps",
"canonicalReference": "@tldraw/tlschema!TLStoreProps:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/createTLSchema.ts",
"releaseTag": "Public",
"name": "TLSchema",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 7
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLScribble:type",
"docComment": "/**\n * A type for the scribble used by tldraw.\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLScribble = "
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "{\n color: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "TLCanvasUiColor",
"canonicalReference": "@tldraw/tlschema!TLCanvasUiColor:type"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": ";\n delay: number;\n id: string;\n opacity: number;\n points: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "VecModel",
"canonicalReference": "@tldraw/tlschema!VecModel:interface"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "[];\n shrink: number;\n size: number;\n state: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "SetValue",
"canonicalReference": "@tldraw/tlschema!~SetValue:type"
},
{
"kind": "Content",
"text": "<typeof "
},
{
"kind": "Reference",
"text": "TL_SCRIBBLE_STATES",
"canonicalReference": "@tldraw/tlschema!~TL_SCRIBBLE_STATES:var"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": ">;\n taper: boolean;\n}"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/misc/TLScribble.ts",
"releaseTag": "Public",
"name": "TLScribble",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 10
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLSerializedStore:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLSerializedStore = "
},
{
"kind": "Reference",
"text": "SerializedStore",
"canonicalReference": "@tldraw/store!SerializedStore:type"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLRecord",
"canonicalReference": "@tldraw/tlschema!TLRecord:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/TLStore.ts",
"releaseTag": "Public",
"name": "TLSerializedStore",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLShape:type",
"docComment": "/**\n * The set of all shapes that are available in the editor, including unknown shapes.\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLShape = "
},
{
"kind": "Reference",
"text": "TLDefaultShape",
"canonicalReference": "@tldraw/tlschema!TLDefaultShape:type"
},
{
"kind": "Content",
"text": " | "
},
{
"kind": "Reference",
"text": "TLUnknownShape",
"canonicalReference": "@tldraw/tlschema!TLUnknownShape:type"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLShape.ts",
"releaseTag": "Public",
"name": "TLShape",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 4
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLShapeId:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLShapeId = "
},
{
"kind": "Reference",
"text": "RecordId",
"canonicalReference": "@tldraw/store!RecordId:type"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLUnknownShape",
"canonicalReference": "@tldraw/tlschema!TLUnknownShape:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLShape.ts",
"releaseTag": "Public",
"name": "TLShapeId",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLShapePartial:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLShapePartial<T extends "
},
{
"kind": "Reference",
"text": "TLShape",
"canonicalReference": "@tldraw/tlschema!TLShape:type"
},
{
"kind": "Content",
"text": " = "
},
{
"kind": "Reference",
"text": "TLShape",
"canonicalReference": "@tldraw/tlschema!TLShape:type"
},
{
"kind": "Content",
"text": "> = "
},
{
"kind": "Content",
"text": "T extends T ? {\n id: "
},
{
"kind": "Reference",
"text": "TLShapeId",
"canonicalReference": "@tldraw/tlschema!TLShapeId:type"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": ";\n meta?: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "Partial",
"canonicalReference": "!Partial:type"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<T['meta']>;\n props?: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "Partial",
"canonicalReference": "!Partial:type"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<T['props']>;\n type: T['type'];\n} & "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "Partial",
"canonicalReference": "!Partial:type"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "Omit",
"canonicalReference": "!Omit:type"
},
{
"kind": "Content",
Remove dependabot config since it only controls version updates? (#3057) 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
2024-03-04 13:19:51 +00:00
"text": "<T, 'id' | 'meta' | 'props' | 'type'>> : never"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLShape.ts",
"releaseTag": "Public",
"name": "TLShapePartial",
"typeParameters": [
{
"typeParameterName": "T",
"constraintTokenRange": {
"startIndex": 1,
"endIndex": 2
},
"defaultTypeTokenRange": {
"startIndex": 3,
"endIndex": 4
}
}
],
"typeTokenRange": {
"startIndex": 5,
"endIndex": 16
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLShapeProp:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLShapeProp = "
},
{
"kind": "Content",
"text": "keyof "
},
{
"kind": "Reference",
"text": "TLShapeProps",
"canonicalReference": "@tldraw/tlschema!TLShapeProps:type"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLShape.ts",
"releaseTag": "Public",
"name": "TLShapeProp",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 3
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLShapeProps:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLShapeProps = "
},
{
"kind": "Reference",
"text": "Identity",
"canonicalReference": "@tldraw/tlschema!~Identity:type"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "UnionToIntersection",
"canonicalReference": "@tldraw/tlschema!~UnionToIntersection:type"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLDefaultShape",
"canonicalReference": "@tldraw/tlschema!TLDefaultShape:type"
},
{
"kind": "Content",
"text": "['props']>>"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLShape.ts",
"releaseTag": "Public",
"name": "TLShapeProps",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 7
}
},
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLShapePropsMigrations:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLShapePropsMigrations = "
},
{
"kind": "Content",
"text": "{\n sequence: "
},
{
"kind": "Reference",
"text": "Array",
"canonicalReference": "!Array:interface"
},
{
"kind": "Content",
"text": "<{\n readonly dependsOn: readonly "
},
{
"kind": "Reference",
"text": "MigrationId",
"canonicalReference": "@tldraw/store!MigrationId:type"
},
{
"kind": "Content",
"text": "[];\n } | {\n readonly dependsOn?: "
},
{
"kind": "Reference",
"text": "MigrationId",
"canonicalReference": "@tldraw/store!MigrationId:type"
},
{
"kind": "Content",
"text": "[];\n readonly down?: ((props: any) => any) | typeof "
},
{
"kind": "Reference",
"text": "NO_DOWN_MIGRATION",
"canonicalReference": "@tldraw/tlschema!~NO_DOWN_MIGRATION:var"
},
{
"kind": "Content",
"text": " | typeof "
},
{
"kind": "Reference",
"text": "RETIRED_DOWN_MIGRATION",
"canonicalReference": "@tldraw/tlschema!~RETIRED_DOWN_MIGRATION:var"
},
{
"kind": "Content",
"text": ";\n readonly id: "
},
{
"kind": "Reference",
"text": "MigrationId",
"canonicalReference": "@tldraw/store!MigrationId:type"
},
{
"kind": "Content",
"text": ";\n readonly up: (props: any) => any;\n }>;\n}"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLShape.ts",
"releaseTag": "Public",
"name": "TLShapePropsMigrations",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 14
}
},
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLStore:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLStore = "
},
{
"kind": "Reference",
"text": "Store",
"canonicalReference": "@tldraw/store!Store:class"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLRecord",
"canonicalReference": "@tldraw/tlschema!TLRecord:type"
},
{
"kind": "Content",
"text": ", "
},
{
"kind": "Reference",
"text": "TLStoreProps",
"canonicalReference": "@tldraw/tlschema!TLStoreProps:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/TLStore.ts",
"releaseTag": "Public",
"name": "TLStore",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 7
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLStoreProps:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLStoreProps = "
},
{
"kind": "Content",
"text": "{\n defaultName: string;\n}"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/TLStore.ts",
"releaseTag": "Public",
"name": "TLStoreProps",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLStoreSchema:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLStoreSchema = "
},
{
"kind": "Reference",
"text": "StoreSchema",
"canonicalReference": "@tldraw/store!StoreSchema:class"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLRecord",
"canonicalReference": "@tldraw/tlschema!TLRecord:type"
},
{
"kind": "Content",
"text": ", "
},
{
"kind": "Reference",
"text": "TLStoreProps",
"canonicalReference": "@tldraw/tlschema!TLStoreProps:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/TLStore.ts",
"releaseTag": "Public",
"name": "TLStoreSchema",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 7
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLStoreSnapshot:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLStoreSnapshot = "
},
{
"kind": "Reference",
"text": "StoreSnapshot",
"canonicalReference": "@tldraw/store!StoreSnapshot:type"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
"text": "TLRecord",
"canonicalReference": "@tldraw/tlschema!TLRecord:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/TLStore.ts",
"releaseTag": "Public",
"name": "TLStoreSnapshot",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLTextShape:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLTextShape = "
},
{
"kind": "Reference",
"text": "TLBaseShape",
"canonicalReference": "@tldraw/tlschema!TLBaseShape:interface"
},
{
"kind": "Content",
"text": "<'text', "
},
{
"kind": "Reference",
"text": "TLTextShapeProps",
"canonicalReference": "@tldraw/tlschema!TLTextShapeProps:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLTextShape.ts",
"releaseTag": "Public",
"name": "TLTextShape",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLTextShapeProps:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLTextShapeProps = "
},
{
"kind": "Reference",
"text": "ShapePropsType",
Stickies: release candidate (#3249) This PR is the target for the stickies PRs that are moving forward. It should collect changes. - [x] New icon - [x] Improved shadows - [x] Shadow LOD - [x] New colors / theme options - [x] Shrink text size to avoid word breaks on the x axis - [x] Hide indicator whilst typing (reverted) - [x] Adjacent note positions - [x] buttons / clone handles - [x] position helpers for creating / translating (pits) - [x] keyboard shortcuts: (Tab, Shift+tab (RTL aware), Cmd-Enter, Shift+Cmd+enter) - [x] multiple shape translating - [x] Text editing - [x] Edit on type (feature flagged) - [x] click goes in correct place - [x] Notes as parents (reverted) - [x] Update colors - [x] Update SVG appearance ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `feature` — New feature ### Test Plan Todo: fold in test plans for child PRs ### Unit tests: - [ ] Shrink text size to avoid word breaks on the x axis - [x] Adjacent notes - [x] buttons (clone handles) - [x] position helpers (pits) - [x] keyboard shortcuts: (Tab, Shift+tab (RTL aware), Cmd-Enter, Shift+Cmd+enter) - [ ] Text editing - [ ] Edit on type - [ ] click goes in correct place ### Release Notes - Improves sticky notes (see list) --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com> Co-authored-by: alex <alex@dytry.ch> Co-authored-by: Mitja Bezenšek <mitja.bezensek@gmail.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Lu[ke] Wilson <l2wilson94@gmail.com> Co-authored-by: huppy-bot[bot] <128400622+huppy-bot[bot]@users.noreply.github.com>
2024-04-14 18:40:02 +00:00
"canonicalReference": "@tldraw/tlschema!ShapePropsType:type"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": "<typeof "
},
{
"kind": "Reference",
"text": "textShapeProps",
"canonicalReference": "@tldraw/tlschema!textShapeProps:var"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLTextShape.ts",
"releaseTag": "Public",
"name": "TLTextShapeProps",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLUnknownShape:type",
"docComment": "/**\n * A type for a shape that is available in the editor but whose type is unknown—either one of the editor's default shapes or else a custom shape.\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLUnknownShape = "
},
{
"kind": "Reference",
"text": "TLBaseShape",
"canonicalReference": "@tldraw/tlschema!TLBaseShape:interface"
},
{
"kind": "Content",
"text": "<string, object>"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/records/TLShape.ts",
"releaseTag": "Public",
"name": "TLUnknownShape",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 3
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLVideoAsset:type",
"docComment": "/**\n * An asset used for videos, used by the TLVideoShape.\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLVideoAsset = "
},
{
"kind": "Reference",
"text": "TLBaseAsset",
"canonicalReference": "@tldraw/tlschema!TLBaseAsset:interface"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<'video', {\n h: number;\n isAnimated: boolean;\n mimeType: null | string;\n name: string;\n src: null | string;\n w: number;\n}>"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/assets/TLVideoAsset.ts",
"releaseTag": "Public",
"name": "TLVideoAsset",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 3
}
},
{
"kind": "TypeAlias",
"canonicalReference": "@tldraw/tlschema!TLVideoShape:type",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "export type TLVideoShape = "
},
{
"kind": "Reference",
"text": "TLBaseShape",
"canonicalReference": "@tldraw/tlschema!TLBaseShape:interface"
},
{
"kind": "Content",
"text": "<'video', "
},
{
"kind": "Reference",
"text": "TLVideoShapeProps",
"canonicalReference": "@tldraw/tlschema!~TLVideoShapeProps:type"
},
{
"kind": "Content",
"text": ">"
},
{
"kind": "Content",
"text": ";"
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLVideoShape.ts",
"releaseTag": "Public",
"name": "TLVideoShape",
"typeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "Interface",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"canonicalReference": "@tldraw/tlschema!VecModel:interface",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"docComment": "/**\n * A serializable model for 2D vectors.\n *\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"text": "export interface VecModel "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/misc/geometry-types.ts",
"releaseTag": "Public",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"name": "VecModel",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"preserveMemberOrder": false,
"members": [
{
"kind": "PropertySignature",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"canonicalReference": "@tldraw/tlschema!VecModel#x:member",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "x: "
},
{
"kind": "Content",
"text": "number"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "x",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"canonicalReference": "@tldraw/tlschema!VecModel#y:member",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "y: "
},
{
"kind": "Content",
"text": "number"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": false,
"releaseTag": "Public",
"name": "y",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
},
{
"kind": "PropertySignature",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"canonicalReference": "@tldraw/tlschema!VecModel#z:member",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"docComment": "",
"excerptTokens": [
{
"kind": "Content",
"text": "z?: "
},
{
"kind": "Content",
"text": "number"
},
{
"kind": "Content",
"text": ";"
}
],
"isReadonly": false,
"isOptional": true,
"releaseTag": "Public",
"name": "z",
"propertyTypeTokenRange": {
"startIndex": 1,
"endIndex": 2
}
}
],
"extendsTokenRanges": []
},
{
"kind": "Variable",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"canonicalReference": "@tldraw/tlschema!vecModelValidator:var",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"text": "vecModelValidator: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
"text": "<"
},
{
"kind": "Reference",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"text": "VecModel",
"canonicalReference": "@tldraw/tlschema!VecModel:interface"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
"text": ">"
}
],
"fileUrlPath": "packages/tlschema/src/misc/geometry-types.ts",
"isReadonly": true,
"releaseTag": "Public",
[tech debt] Primitives renaming party / cleanup (#2396) This PR: - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers - removes unused exports - removes a few redundant tests in dgreensp ### Change Type - [x] `major` — Breaking change ### Release Notes - renames Vec2d to Vec - renames Vec2dModel to VecModel - renames Box2d to Box - renames Box2dModel to BoxModel - renames Matrix2d to Mat - renames Matrix2dModel to MatModel - removes unused primitive helpers
2024-01-03 12:13:15 +00:00
"name": "vecModelValidator",
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 5
}
},
{
"kind": "Variable",
"canonicalReference": "@tldraw/tlschema!videoShapeProps:var",
"docComment": "/**\n * @public\n */\n",
"excerptTokens": [
{
"kind": "Content",
"text": "videoShapeProps: "
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "{\n assetId: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<import(\"..\")."
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "TLAssetId",
"canonicalReference": "@tldraw/tlschema!TLAssetId:type"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": " | null>;\n h: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
"text": "<number>;\n playing: "
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<boolean>;\n time: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<number>;\n url: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<string>;\n w: "
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Reference",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "T.Validator",
"canonicalReference": "@tldraw/validate!Validator:class"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
},
{
"kind": "Content",
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural 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 #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
"text": "<number>;\n}"
Publish api.json (#2034) This PR publishes the api.json files created by the build-api scripts. ### Change Type - [x] `internal`
2023-10-08 15:00:58 +00:00
}
],
"fileUrlPath": "packages/tlschema/src/shapes/TLVideoShape.ts",
"isReadonly": true,
"releaseTag": "Public",
"name": "videoShapeProps",
"variableTypeTokenRange": {
"startIndex": 1,
"endIndex": 16
}
}
]
}
]
}
Reference in a new issue Copy permalink