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
@@ -11,324 +11,76 @@ jtd-codebuild is a tool for generating language specific schemas and interfaces
11
11
12
12
This tool is built on top of [jtd-codegen](https://jsontypedef.com/docs/jtd-codegen/) so check out the documentation if you don't have a clue about JSON Type Definition.
13
13
14
-
## Quickstart
14
+
## Quick Example
15
15
16
-
First, initialize the configuration file by running the command below.
16
+
In this example, we will generate Python and TypeScript code from JSON Type Definition IDL files.
17
17
18
-
```bash
19
-
jtd-codebuild --init
20
-
```
21
-
22
-
## Installation
23
-
24
-
```bash
25
-
pip install jtd-codebuild
26
-
```
27
-
28
-
## Usage
29
-
30
-
First, you need to create a configuration file named `jtd-codebuild.json` in the root of your project. (See [Configuration](#configuration))
31
-
32
-
Then, write JSON type definition IDL files in either yaml or json format in the directory you specified in the configuration file.
33
-
34
-
After all of that, you can run the command below to generate code.
You can find the example project here: [jtd_codebuild/tests/fixtures/example_project_1](./jtd_codebuild/tests/fixtures/example_project_1)
43
-
44
-
Also, you can get a sense of how this tool works by looking at the test cases: [jtd_codebuild/tests/test_example_project_1.py](./jtd_codebuild/tests/test_example_project_1.py)
45
-
46
-
47
-
## Required conventions
48
-
49
-
### Configuration
50
-
51
-
The script will find `jtd-codebuild.json` which is the configuration file of this tooling.
52
-
53
-
#### `root-schema-path`
54
-
55
-
The path to the root schema file.
56
-
Root schema file will be the entry point of the code generation,
This directory will be recursively searched for definition files.
65
-
66
-
Definition file is a file that contains a single or multiple definitions.
67
-
Checkout the documentation below for more information.
68
-
69
-
Defaults to `[]`
70
-
71
-
#### `output-schema-path`
72
-
73
-
The path for the merged schema file converted in json format.
18
+
First, copy and paste the following configuration file to the root of your project.
74
19
75
-
Defaults to `gen/schema.jtd.json`
76
-
77
-
#### `includes`
78
-
79
-
Array of JTD package paths to include.
80
-
81
-
The path should have `jtd-codebuild.json` file in it
82
-
so that this tool can find the codebuild configuration.
83
-
84
-
If you specifiy a package path,
85
-
it will reference the package's schema definitions
86
-
when generating schema file you are working on.
87
-
88
-
Defaults to `[]`
89
-
90
-
#### `allow-duplicate-defs`
91
-
92
-
Whether to allow duplicate definitions.
93
-
94
-
This only applies to the definitions that are not in the same jtd codebuild project.
95
-
96
-
That is, definitions in `definitions-path` in each project always raises error if there are duplicate definitions.
97
-
98
-
Defaults to `false`
99
-
100
-
#### `targets`
101
-
102
-
Compile targets.
103
-
104
-
Defaults to `[]`
105
-
106
-
It's a JSONRecord contains the object having following properties:
107
-
-`language (string)`: The language of the target.
108
-
We essentially inject this value to `jtd-codegen` as target language option
109
-
which is provided as a flag which is like `--{language}-out`.
110
-
Available languages can be found in the documentation of `jtd-codegen`.
111
-
(See: https://jsontypedef.com/)
112
-
-`path (string)`: The path to the directory where the generated code will be placed.
113
-
114
-
##### `targets` - Language Specific Options - Python
115
-
116
-
-`use-pydantic (boolean)`: Whether to use pydantic as a `dataclass` decorator provider.
117
-
If this is set to true, the generated code will use `pydantic.dataclasses.dataclass` as a `dataclass` decorator so that you can use pydantic's validation features.
118
-
Otherwise, the generated code will be plain python dataclasses.
119
-
Defaults to `false`.
120
-
-`use-typeddict (boolean)`: Whether to use `TypedDict` instead of `dataclass`.
121
-
If this is set to true, the generated code will use `TypedDict` instead of `dataclass`. This property cannot be set to true if `use-pydantic` is set to true. Also, subscriptable option will be ignored if this is set to true.
122
-
-`property-case (enum)`: The case of the property names.
123
-
This property is only effective when `use-typeddict` is set to true.
124
-
Available values are `snake` and `camel`.
125
-
Defaults to `snake`.
126
-
-`subscriptable (boolean)`: Whether to make the generated class subscriptable.
127
-
If this is set to true, the generated class will be subscriptable so that you can access the properties of the class like `obj["property"]`.
128
-
Otherwise, the generated class will not be subscriptable.
129
-
Defaults to `false`.
130
-
131
-
##### `targets` - Language Specific Options - TypeScript
132
-
133
-
-`tsconfig-path (string)`: The path to the tsconfig file.
134
-
This will be used to compile typescript code
135
-
to javascript code and type declarations.
136
-
If you want to automatically generate
137
-
plain javascript artifact with type declarations,
138
-
you should also provide this option.
139
-
140
-
141
-
### Configuration Example
142
-
143
-
Example congfiguration file is provided below. Copy it and modify it to your needs.
Root schema file is the entry point of the code generation.
180
-
181
-
It will be the file where every definition files will be merged into.
182
-
183
-
If you don't need a root `Schema` type, you can just create an empty file.
184
-
185
-
### Definition files
186
-
187
-
Definition files are sharable files of which each of them contains a single or multiple definitions.
188
-
189
-
Each declared keys as a root key in the definition file will be merged as a key of `definitions` object in the root schema file, and those symbols can be shared across the other definition files.
190
-
191
-
For example, let's say you have a definition file whose code is like below.
41
+
Then, we'll create some JSON Type Definition IDL files in the `src` directory.
192
42
193
43
```yaml
194
-
book:
44
+
# src/book.jtd.yaml
45
+
Book:
195
46
properties:
196
47
id:
197
48
type: string
198
49
title:
199
50
type: string
200
51
```
201
-
202
-
This can be referenced in other definition files like below.
203
-
204
52
```yaml
205
-
user:
53
+
# src/user.jtd.yaml
54
+
User:
206
55
properties:
207
56
id:
208
57
type: string
209
58
name:
210
59
type: string
211
60
books:
212
61
elements:
213
-
ref: book
214
-
```
215
-
216
-
This will be merged as a single schema like below.
217
-
218
-
```json
219
-
{
220
-
"definitions": {
221
-
"book": {
222
-
"properties": {
223
-
"id": {
224
-
"type": "string"
225
-
},
226
-
"title": {
227
-
"type": "string"
228
-
}
229
-
}
230
-
},
231
-
"user": {
232
-
"properties": {
233
-
"id": {
234
-
"type": "string"
235
-
},
236
-
"name": {
237
-
"type": "string"
238
-
},
239
-
"books": {
240
-
"elements": {
241
-
"ref": "book"
242
-
}
243
-
}
244
-
}
245
-
}
246
-
}
247
-
}
248
-
```
249
-
250
-
Checkout more about `ref` if you don't have a clue about it. https://jsontypedef.com/docs/jtd-in-5-minutes/#ref-schemas
251
-
252
-
### Inheritance
253
-
254
-
`jtd-codebuild` supports inheritance between type definitions.
255
-
256
-
You can do this by using `extends` keyword like below.
257
-
258
-
```yaml
259
-
Person:
260
-
properties:
261
-
id:
262
-
type: string
263
-
name:
264
-
type: string
265
-
266
-
Chef:
267
-
extends: Person
268
-
properties:
269
-
restaurant:
270
-
type: string
271
-
272
-
HeadChef:
273
-
extends: Chef
274
-
properties:
275
-
sousChef:
276
-
ref: Chef
62
+
ref: Book
277
63
```
278
64
279
-
You can also extend multiple types like below.
280
-
281
-
```yaml
282
-
Person:
283
-
properties:
284
-
id:
285
-
type: string
286
-
name:
287
-
type: string
288
-
289
-
MyRestaurantMixin:
290
-
properties:
291
-
restaurant:
292
-
type: string
65
+
Finally, run the following command to generate the code.
293
66
294
-
Chef:
295
-
extends: [Person, MyRestaurantMixin]
67
+
```bash
68
+
jtd-codebuild .
296
69
```
297
70
298
-
### Manual dependency management
299
-
300
-
Since IDL files are basically just a bunch of JSON objects,
301
-
we need to manually manage the dependency between the definition files.
71
+
You can find the generated code in the `gen` directory.
302
72
303
-
For example, assume you have a folder structure like the below:
73
+
## More Examples
304
74
305
-
```
306
-
definitions
307
-
├── book
308
-
│ └── book.jtd.yaml
309
-
└── user
310
-
└── user.jtd.yaml
311
-
```
75
+
You can find more examples under the [tests] directory:
312
76
313
-
And assume that `book.jtd.yaml` and `user.jtd.yaml` are the root definition files of each module.
0 commit comments