You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+11-2Lines changed: 11 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,9 +23,17 @@
23
23
<img src="https://img.shields.io/badge/License-MIT-blue.svg" alt="Typesync CLI is released under the MIT license." /></a>
24
24
</p>
25
25
26
-
Typesync is an open-source schema management tool that simplifies managing [Firestore](https://cloud.google.com/firestore) databases. Typesync allows you to maintain a single source of truth for your Firestore architecture in a special _schema_. With this schema in place, you can seamlessly auto-generate type definitions for multiple platforms like TypeScript, Swift, Python, and more using the CLI tool.
26
+
Typesync is an open-source schema management tool for [Firestore](https://cloud.google.com/firestore) databases. You maintain a single source of truth for your Firestore architecture in a _schema_, then use the CLI to generate code and validate data from that schema.
27
27
28
-
Typesync keeps your database and application code consistent and up-to-date at all times. In addition to type definitions, it lets you generate other useful things like Security Rules, Mermaid graphs visualizing your database architecture and documentation for your data models.
28
+
Typesync helps keep your database, generated application code, and validation checks aligned as your schema changes.
29
+
30
+
# How Typesync Helps You
31
+
32
+
- Generate Firestore models for TypeScript, Swift, and Python from one schema.
33
+
- Validate live Firestore documents with `typesync validate-data`.
34
+
- Generate Security Rules validators from the same model definitions.
35
+
- Visualize your Firestore architecture with Mermaid graphs.
36
+
- Carry schema documentation into generated model output.
29
37
30
38
[**View the full documentation (docs) ▸**](https://docs.typesync.org)
31
39
@@ -42,6 +50,7 @@ Explore our comprehensive [documentation](https://docs.typesync.org) for detaile
42
50
-[Quickstart](https://docs.typesync.org/quickstart): Get up and running with Typesync quickly.
43
51
-[Upgrading](https://docs.typesync.org/upgrading): Guidelines on upgrading to the latest version of the CLI.
44
52
-[Types](https://docs.typesync.org/schema/types): Details on the types supported by Typesync’s type system.
53
+
-[validate-data](https://docs.typesync.org/cli/validate-data): Validate Firestore documents against your schema.
Generates a [Mermaid](https://mermaid.js.org) graph for the specified schema and injects it into the specified Markdown file. The generated graph is the visual representation of the database architecture inferred from your schema. You can specify where the graph is inserted within the file using the `--startMarker` and `--endMarker` options. For a detailed guide, see the full [example](#example) below.
Generates Python/Pydantic type definitions for the specified schema and writes them to the specified file. Typesync first “flattens” your schema, creating new aliases for inline types defined within. It then generates the classes, enums, aliases, etc. including serializers and deserializers.
Generates validator functions for Firestore Security Rules (version 2) and injects them into the specified file. These validators ensure that request data adheres to defined model interfaces and detect any modifications to read-only fields during write operations.
15
15
16
16
Since Security Rules are centralized in a single file (typically `firestore.rules`), and developers often implement custom rules alongside type validations, Typesync inserts only the necessary validator functions, without overriding your custom rules. You can specify where these validators are added within the file using the `--startMarker` and `--endMarker` options. For a detailed guide, see the full [example](#example) below.
17
17
18
18
<Info>
19
-
Note that these validators must adhere to the intrinsic limitations of
20
-
Security Rules. For example, while it's feasible to verify if `x` is a list
21
-
with the `x is list` predicate, determining whether it's a list of strings is
22
-
not possible since loop constructs are not available in Security Rules.
23
-
Typesync will provide the most stringent validation possible within these
24
-
constraints.
19
+
Note that these validators must adhere to the intrinsic limitations of Security Rules. For example, while it's
20
+
feasible to verify if `x` is a list with the `x is list` predicate, determining whether it's a list of strings is not
21
+
possible since loop constructs are not available in Security Rules. Typesync will provide the most stringent
The name of the parameter taken by each type validator.
69
66
</ParamField>
70
67
71
-
{/* <ParamField
72
-
type="string"
73
-
path="readonlyFieldValidatorNamePattern"
74
-
default="isReadonlyFieldAffectedFor{modelName}"
75
-
>
76
-
The pattern that specifies how the generated readonly field validators are named. The pattern must be a string that contains the `"{modelName}"` substring (this is a literal value).
77
-
78
-
Example values:
68
+
{/\* <ParamField
69
+
type="string"
70
+
path="readonlyFieldValidatorNamePattern"
71
+
default="isReadonlyFieldAffectedFor{modelName}"
72
+
73
+
> The pattern that specifies how the generated readonly field validators are named. The pattern must be a string that contains the `"{modelName}"` substring (this is a literal value).
74
+
75
+
Example values:
79
76
80
77
- `"isReadonlyFieldAffectedFor{modelName}"` -> produces validators like `isReadonlyFieldAffectedForUser`, `isReadonlyFieldAffectedForProject`, `isReadonlyFieldAffectedForAccount` etc.
81
78
- `"affectsReadonlyFieldFor{modelName}"` -> produces validators like `affectsReadonlyFieldForUser`, `affectsReadonlyFieldForProject`, `affectsReadonlyFieldForAccount` etc.
82
79
83
80
</ParamField> */}
84
81
85
-
{/* <ParamField
86
-
type="string"
87
-
path="readonlyFieldValidatorPrevDataParamName"
88
-
default="prevData"
89
-
>
90
-
The name of the first parameter taken by each readonly field validator
91
-
representing previous data. This parameter used when computing the diff
92
-
between next data and previous data to determine whether a readonly field has
93
-
been affected by a write.
82
+
{/\* <ParamField
83
+
type="string"
84
+
path="readonlyFieldValidatorPrevDataParamName"
85
+
default="prevData"
86
+
87
+
> The name of the first parameter taken by each readonly field validator
88
+
> representing previous data. This parameter used when computing the diff
89
+
> between next data and previous data to determine whether a readonly field has
90
+
> been affected by a write.
91
+
94
92
</ParamField> */}
95
93
96
-
{/* <ParamField
97
-
type="string"
98
-
path="readonlyFieldValidatorNextDataParamName"
99
-
default="nextData"
100
-
>
101
-
The name of the second parameter taken by each readonly field validator
102
-
representing next data. This parameter used when computing the diff between
103
-
next data and previous data to determine whether a readonly field has been
104
-
affected by a write.
94
+
{/\* <ParamField
95
+
type="string"
96
+
path="readonlyFieldValidatorNextDataParamName"
97
+
default="nextData"
98
+
99
+
> The name of the second parameter taken by each readonly field validator
100
+
> representing next data. This parameter used when computing the diff between
101
+
> next data and previous data to determine whether a readonly field has been
102
+
> affected by a write.
103
+
105
104
</ParamField> */}
106
105
107
106
<IndentationOption />
@@ -116,7 +115,6 @@ Suppose you have a schema definition file named `models.yml` and a Security Rule
116
115
<ExampleGenerationRulesBefore />
117
116
</CodeGroup>
118
117
119
-
120
118
{/* TODO: Update */}
121
119
122
120
To generate validators for the defined models and inject them between the `typesync-start` and `typesync-end` markers in the `firestore.rules` file, you can run the following command:
Generates Swift type definitions for the specified schema and writes them to the specified file. Typesync first "flattens" your schema, creating new aliases for inline types defined within. It then generates the primary and auxiliary structs, enums, aliases, etc. including encoders and decoders.
12
+
Generates Swift type definitions for the specified schema and writes them to the specified file. Typesync first "flattens" your schema, creating new aliases for inline types defined within. It then generates the primary and auxiliary structs, enums, aliases, encoders, and decoders.
13
+
14
+
For document models, generated Swift structs include an `@DocumentID var id: String?` property by default. The Firebase Apple SDK fills this value from the document path when decoding and excludes it from the encoded document body when writing.
0 commit comments