cabloy 5.1.57 → 5.1.59
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +23 -0
- package/cabloy-docs/.vitepress/config.mjs +1 -0
- package/cabloy-docs/backend/dto-guide.md +7 -0
- package/cabloy-docs/backend/orm-select-guide.md +2 -0
- package/cabloy-docs/backend/validation-guide.md +8 -0
- package/cabloy-docs/fullstack/comparison-with-other-frameworks.md +1 -0
- package/cabloy-docs/fullstack/framework-performance.md +89 -0
- package/cabloy-docs/fullstack/introduction.md +1 -0
- package/cabloy-docs/fullstack/quickstart.md +19 -3
- package/cabloy-docs/fullstack/vona-zova-integration.md +2 -0
- package/cabloy-docs/index.md +8 -0
- package/package.json +1 -1
- package/scripts/upgrade.ts +6 -0
- package/vona/packages-cli/cli/package.json +1 -1
- package/vona/packages-cli/cli-set-api/package.json +1 -1
- package/vona/packages-utils/zod-query/package.json +1 -1
- package/vona/packages-utils/zod-query/src/index.ts +1 -0
- package/vona/packages-utils/zod-query/src/lib/query.ts +31 -12
- package/vona/packages-utils/zod-query/src/lib/zod-is-type.ts +48 -6
- package/vona/packages-vona/vona/package.json +1 -1
- package/vona/packages-vona/vona-core/package.json +1 -1
- package/vona/packages-vona/vona-mock/package.json +1 -1
- package/vona/pnpm-lock.yaml +482 -477
- package/vona/src/suite-vendor/a-vona/modules/a-core/package.json +1 -1
- package/vona/src/suite-vendor/a-vona/modules/a-openapi/package.json +1 -1
- package/vona/src/suite-vendor/a-vona/modules/a-openapiutils/package.json +1 -1
- package/vona/src/suite-vendor/a-vona/modules/a-openapiutils/src/lib/schema/v/system.ts +6 -0
- package/vona/src/suite-vendor/a-vona/modules/a-openapiutils/src/lib/schema/v.ts +2 -0
- package/vona/src/suite-vendor/a-vona/modules/a-web/package.json +1 -1
- package/vona/src/suite-vendor/a-vona/modules/a-web/src/bean/filterTransform.base.ts +6 -0
- package/vona/src/suite-vendor/a-vona/modules/a-web/src/bean/filterTransform.dateRange.ts +1 -0
- package/vona/src/suite-vendor/a-vona/modules/a-web/src/bean/pipe.filter.ts +5 -5
- package/vona/src/suite-vendor/a-vona/package.json +1 -1
- package/zova/packages-utils/zova-jsx/package.json +2 -2
- package/zova/packages-zova/zova/package.json +3 -3
- package/zova/packages-zova/zova-core/package.json +2 -2
- package/zova/src/suite-vendor/a-zova/modules/a-zod/package.json +2 -2
- package/zova/src/suite-vendor/a-zova/modules/a-zova/package.json +2 -2
- package/zova/src/suite-vendor/a-zova/package.json +3 -3
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,28 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## 5.1.59
|
|
4
|
+
|
|
5
|
+
### Features
|
|
6
|
+
|
|
7
|
+
- Update functionality.
|
|
8
|
+
|
|
9
|
+
### Improvements
|
|
10
|
+
|
|
11
|
+
- Update `upgrade.ts`.
|
|
12
|
+
- Publish the latest package changes.
|
|
13
|
+
|
|
14
|
+
## 5.1.58
|
|
15
|
+
|
|
16
|
+
### Features
|
|
17
|
+
|
|
18
|
+
- Support nullable query filters.
|
|
19
|
+
- Deliver several feature updates across the library.
|
|
20
|
+
|
|
21
|
+
### Improvements
|
|
22
|
+
|
|
23
|
+
- Add a Docker Compose quickstart flow to the documentation.
|
|
24
|
+
- Refresh the framework performance documentation.
|
|
25
|
+
|
|
3
26
|
## 5.1.57
|
|
4
27
|
|
|
5
28
|
### Features
|
|
@@ -53,6 +53,7 @@ const fullstackGroups = [
|
|
|
53
53
|
text: 'Comparison with Other Frameworks',
|
|
54
54
|
link: '/fullstack/comparison-with-other-frameworks',
|
|
55
55
|
},
|
|
56
|
+
{ text: 'Framework Performance', link: '/fullstack/framework-performance' },
|
|
56
57
|
{ text: 'Vona + Zova Integration', link: '/fullstack/vona-zova-integration' },
|
|
57
58
|
{ text: 'Backend OpenAPI to Frontend SDK', link: '/fullstack/openapi-to-sdk' },
|
|
58
59
|
{
|
|
@@ -73,6 +73,13 @@ class DtoStudentCreate {
|
|
|
73
73
|
}
|
|
74
74
|
```
|
|
75
75
|
|
|
76
|
+
For query-oriented DTOs, another important distinction is optional vs nullable:
|
|
77
|
+
|
|
78
|
+
- `v.optional()` means the field may be omitted
|
|
79
|
+
- `v.nullable()` means the field may carry a real `null`
|
|
80
|
+
|
|
81
|
+
That becomes especially important for DTO query filters. A field declared with `v.optional(), v.nullable()` can preserve real `null` through query parsing so the downstream ORM filter can express SQL `IS NULL` instead of silently treating the value as omitted.
|
|
82
|
+
|
|
76
83
|
## DTO options
|
|
77
84
|
|
|
78
85
|
Three especially important DTO option areas are:
|
|
@@ -146,6 +146,8 @@ await this.scope.model.post.select({
|
|
|
146
146
|
|
|
147
147
|
This lets a query builder remove one condition cleanly without rebuilding the whole `where` object by hand, while `null` remains available for SQL `IS NULL` semantics.
|
|
148
148
|
|
|
149
|
+
That distinction also matters at the request-contract layer: omitting a nullable filter and passing a real `null` are different operations. When a query DTO needs `IS NULL` behavior from frontend query params, the parsing contract must explicitly preserve `null` instead of collapsing it to omission.
|
|
150
|
+
|
|
149
151
|
## Joint operators and subqueries
|
|
150
152
|
|
|
151
153
|
The query language also supports joint operators such as:
|
|
@@ -37,12 +37,20 @@ findOne(@Arg.query('id', z.number().min(6)) id: number) {}
|
|
|
37
37
|
Inferred schemas can also be extended through helper tools like:
|
|
38
38
|
|
|
39
39
|
- `v.optional`
|
|
40
|
+
- `v.nullable`
|
|
40
41
|
- `v.default`
|
|
41
42
|
- `v.array`
|
|
42
43
|
- `v.lazy`
|
|
43
44
|
|
|
44
45
|
That is important because many real validation cases need augmentation rather than total replacement.
|
|
45
46
|
|
|
47
|
+
A useful distinction is:
|
|
48
|
+
|
|
49
|
+
- `v.optional` means the field may be omitted
|
|
50
|
+
- `v.nullable` means the field may carry a real `null`
|
|
51
|
+
|
|
52
|
+
For query parameters, that distinction matters because plain optional values still collapse `null` to omission, while `v.optional(), v.nullable()` allows a real `null` to survive parsing when the contract needs SQL `IS NULL` semantics downstream.
|
|
53
|
+
|
|
46
54
|
## `@Arg.filter`
|
|
47
55
|
|
|
48
56
|
The validation layer also supports more advanced query-style inputs through `@Arg.filter`, which ties into DTO/query helper structures.
|
|
@@ -11,6 +11,7 @@ That means the comparison is not only about a backend runtime or only about a fr
|
|
|
11
11
|
For the broader Cabloy model, start with these pages:
|
|
12
12
|
|
|
13
13
|
- [Fullstack Introduction](/fullstack/introduction)
|
|
14
|
+
- [Framework Performance](/fullstack/framework-performance)
|
|
14
15
|
- [Vona + Zova Integration](/fullstack/vona-zova-integration)
|
|
15
16
|
- [Backend OpenAPI to Frontend SDK](/fullstack/openapi-to-sdk)
|
|
16
17
|
- [Frontend Metadata Back to Backend](/fullstack/frontend-metadata-to-backend)
|
|
@@ -0,0 +1,89 @@
|
|
|
1
|
+
# Framework Performance
|
|
2
|
+
|
|
3
|
+
Cabloy is designed to stay fast where real systems usually become fragile: under growing business complexity.
|
|
4
|
+
|
|
5
|
+
Its performance story is not only about looking fast in simplified demos. It is about keeping real business systems maintainable, expressive, and performant as they grow in size and complexity.
|
|
6
|
+
|
|
7
|
+
This page explains that philosophy first, then shows a concrete runtime example from an internally generated project.
|
|
8
|
+
|
|
9
|
+
## Philosophy
|
|
10
|
+
|
|
11
|
+
Many frameworks highlight performance with simplified cases, but real systems face a different challenge: as business complexity grows, performance work can easily turn into a growing pile of special-case optimization code.
|
|
12
|
+
|
|
13
|
+
Cabloy takes a different direction.
|
|
14
|
+
|
|
15
|
+
At the framework level, the goal is not only to make one isolated path faster. The goal is to let teams build large-scale systems in a way that stays elegant, maintainable, and performance-aware over time.
|
|
16
|
+
|
|
17
|
+
That philosophy comes from the earlier Vona design direction:
|
|
18
|
+
|
|
19
|
+
- performance should be considered under real business complexity
|
|
20
|
+
- framework support should reduce the amount of ad hoc optimization code that teams need to write themselves
|
|
21
|
+
- maintainability and performance should improve together instead of fighting each other
|
|
22
|
+
|
|
23
|
+
In other words, Cabloy does not treat performance as a last-minute patch. It treats performance-related capability as part of the framework design.
|
|
24
|
+
|
|
25
|
+
## What supports this philosophy
|
|
26
|
+
|
|
27
|
+
A practical example is **Vona** on the backend side.
|
|
28
|
+
|
|
29
|
+
Vona moves caching into the framework core instead of treating caching as something every project must rebuild from scratch. That includes framework-managed cache behavior such as:
|
|
30
|
+
|
|
31
|
+
- entity cache
|
|
32
|
+
- query cache
|
|
33
|
+
- broader cache-centered workflow support for complex data access paths
|
|
34
|
+
|
|
35
|
+
This matters because large systems usually do not become slow only because one query is inefficient. They become slow because optimization logic gets scattered across the codebase and becomes difficult to keep correct.
|
|
36
|
+
|
|
37
|
+
By making caching first-class, Cabloy helps teams keep performance work closer to the framework model and farther away from repetitive custom optimization code.
|
|
38
|
+
|
|
39
|
+
For the current public explanation of this backend capability, see [Cache Guide](/backend/cache-guide).
|
|
40
|
+
|
|
41
|
+
## Runtime example
|
|
42
|
+
|
|
43
|
+
This is the kind of result Cabloy is designed to support: a framework that stays operationally calm even when the system keeps running for long periods.
|
|
44
|
+
|
|
45
|
+
One internally generated project was kept running continuously for **33 hours**. At one representative PM2 snapshot, the process looked like this:
|
|
46
|
+
|
|
47
|
+
```text
|
|
48
|
+
┌────┬─────────────────┬─────────────┬─────────┬─────────┬──────────┬────────┬──────┬───────────┬──────────┬──────────┬──────────┬──────────┐
|
|
49
|
+
│ id │ name │ namespace │ version │ mode │ pid │ uptime │ ↺ │ status │ cpu │ mem │ user │ watching │
|
|
50
|
+
├────┼─────────────────┼─────────────┼─────────┼─────────┼──────────┼────────┼──────┼───────────┼──────────┼──────────┼──────────┼──────────┤
|
|
51
|
+
│ 0 │ cabloy_store │ default │ N/A │ cluster │ 226947 │ 33h │ 17 │ online │ 0% │ 401.9mb │ ubuntu │ disabled │
|
|
52
|
+
└────┴─────────────────┴─────────────┴─────────┴─────────┴──────────┴────────┴──────┴───────────┴──────────┴──────────┴──────────┴──────────┘
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
For this 33-hour continuous run, the observed result was **0 memory leak**.
|
|
56
|
+
|
|
57
|
+
The value of this example is not that it is a synthetic micro-benchmark. The value is that it reflects a real long-running project process with a clear, inspectable runtime footprint.
|
|
58
|
+
|
|
59
|
+
## How to read this example
|
|
60
|
+
|
|
61
|
+
This example is meant to show a real runtime stability observation from an internal project.
|
|
62
|
+
|
|
63
|
+
It should not be read as:
|
|
64
|
+
|
|
65
|
+
- a formal benchmark against other frameworks
|
|
66
|
+
- a universal guarantee for every Cabloy workload
|
|
67
|
+
- proof that every deployment will show the same memory profile
|
|
68
|
+
|
|
69
|
+
Actual memory usage still depends on factors such as:
|
|
70
|
+
|
|
71
|
+
- enabled modules and features
|
|
72
|
+
- request traffic patterns
|
|
73
|
+
- data volume
|
|
74
|
+
- deployment topology
|
|
75
|
+
- operational configuration
|
|
76
|
+
|
|
77
|
+
If you want to check your own SSR workload, you can use the `detect-ssr-leak` Claude skill in the Vona workspace to investigate long-running memory behavior and verify whether the system shows leak signals.
|
|
78
|
+
|
|
79
|
+
This is a diagnostic workflow, not a universal guarantee that every deployment is leak-free.
|
|
80
|
+
|
|
81
|
+
So the point of the example is not that one PM2 snapshot explains everything. The point is that Cabloy’s framework design is intended to support long-running, real business systems without forcing teams into constant performance firefighting.
|
|
82
|
+
|
|
83
|
+
## Where to go next
|
|
84
|
+
|
|
85
|
+
If you want to continue from the performance philosophy into the concrete framework mechanisms behind it, these pages are the best next stops:
|
|
86
|
+
|
|
87
|
+
- [Cache Guide](/backend/cache-guide) — how Vona makes caching first-class in the backend model
|
|
88
|
+
- [Vona + Zova Integration](/fullstack/vona-zova-integration) — how the backend and frontend stay aligned as one framework system
|
|
89
|
+
- [Backend OpenAPI to Frontend SDK](/fullstack/openapi-to-sdk) — one example of how Cabloy reduces repetitive cross-stack work at scale
|
|
@@ -41,6 +41,7 @@ Start here when you want the shortest route to a working monorepo mental model:
|
|
|
41
41
|
Use this path when the task is about how backend and frontend stay aligned inside one framework system:
|
|
42
42
|
|
|
43
43
|
- [Comparison with Other Frameworks](/fullstack/comparison-with-other-frameworks)
|
|
44
|
+
- [Framework Performance](/fullstack/framework-performance)
|
|
44
45
|
- [Vona + Zova Integration](/fullstack/vona-zova-integration)
|
|
45
46
|
- [Backend OpenAPI to Frontend SDK](/fullstack/openapi-to-sdk)
|
|
46
47
|
- [Frontend Metadata Back to Backend](/fullstack/frontend-metadata-to-backend)
|
|
@@ -57,13 +57,29 @@ If you are not sure which edition you are using or which one to choose, read:
|
|
|
57
57
|
- [Cabloy Basic](/editions/cabloy-basic)
|
|
58
58
|
- [Cabloy Start](/editions/cabloy-start)
|
|
59
59
|
|
|
60
|
-
## 5.
|
|
60
|
+
## 5. Run with Docker Compose
|
|
61
|
+
|
|
62
|
+
Both Cabloy Basic and Cabloy Start support the same Docker Compose command flow. Run these commands from the repository for the edition you are using:
|
|
63
|
+
|
|
64
|
+
```bash
|
|
65
|
+
npm run build:docker
|
|
66
|
+
cd docker-compose
|
|
67
|
+
sudo COMPOSE_BAKE=true docker-compose build
|
|
68
|
+
sudo docker-compose up
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
- Web: http://localhost/
|
|
72
|
+
- Admin: http://localhost/admin/
|
|
73
|
+
|
|
74
|
+
These commands build the edition-specific frontend flavors from the repository you are using.
|
|
75
|
+
|
|
76
|
+
## 6. Upgrade an existing project
|
|
61
77
|
|
|
62
78
|
```bash
|
|
63
79
|
npm run upgrade
|
|
64
80
|
```
|
|
65
81
|
|
|
66
|
-
##
|
|
82
|
+
## 7. Next steps for framework-aware development
|
|
67
83
|
|
|
68
84
|
If you are contributing to framework-aware workflows or using Cabloy CLI generation directly, prefer CLI-backed generation over manual scaffolding.
|
|
69
85
|
|
|
@@ -76,7 +92,7 @@ npm run zova :create
|
|
|
76
92
|
|
|
77
93
|
Then narrow into the specific command family you need.
|
|
78
94
|
|
|
79
|
-
##
|
|
95
|
+
## 8. Shared verification commands for deeper workflow checks
|
|
80
96
|
|
|
81
97
|
If you are validating framework-aware changes or a broader workflow, use the shared project scripts before declaring a workflow correct:
|
|
82
98
|
|
|
@@ -23,6 +23,8 @@ Cabloy uses a frontend-backend separation architecture:
|
|
|
23
23
|
- generated or built frontend output is consumed by the backend-side fullstack flow
|
|
24
24
|
- type sharing is coordinated through OpenAPI, generated SDKs, and frontend-generated route/component typing
|
|
25
25
|
|
|
26
|
+
For the framework-level performance philosophy behind this fullstack model, see [Framework Performance](/fullstack/framework-performance).
|
|
27
|
+
|
|
26
28
|
## Cabloy Basic
|
|
27
29
|
|
|
28
30
|
In Cabloy Basic, the root repository already exposes these shared entrypoints:
|
package/cabloy-docs/index.md
CHANGED
|
@@ -42,6 +42,7 @@ Start here to learn the shared Cabloy architecture, see how Vona and Zova fit to
|
|
|
42
42
|
- **Get started quickly** with the fullstack quickstart and core Cabloy concepts
|
|
43
43
|
- **Learn the shared fullstack architecture** across Cabloy, Vona, and Zova
|
|
44
44
|
- **Explore backend and frontend workflows** without losing the cross-stack picture
|
|
45
|
+
- **Understand Cabloy’s performance philosophy and runtime stability story** with [Framework Performance](/fullstack/framework-performance)
|
|
45
46
|
- **See how Cabloy Basic and Cabloy Start differ by edition** when UI assumptions, flavors, modules, SSR sites, or AI workflow guidance matter
|
|
46
47
|
- **Follow source-grounded AI vibe coding guidance** for prompting, workflow selection, and verification
|
|
47
48
|
|
|
@@ -63,6 +64,13 @@ Start here to learn the shared Cabloy architecture, see how Vona and Zova fit to
|
|
|
63
64
|
5. [Reference Introduction](/reference/introduction)
|
|
64
65
|
6. [Editions Overview](/editions/overview)
|
|
65
66
|
|
|
67
|
+
### For performance-oriented reading
|
|
68
|
+
|
|
69
|
+
1. [Fullstack Introduction](/fullstack/introduction)
|
|
70
|
+
2. [Framework Performance](/fullstack/framework-performance)
|
|
71
|
+
3. [Cache Guide](/backend/cache-guide)
|
|
72
|
+
4. [Vona + Zova Integration](/fullstack/vona-zova-integration)
|
|
73
|
+
|
|
66
74
|
## Documentation scope labels
|
|
67
75
|
|
|
68
76
|
Use these labels throughout the site:
|
package/package.json
CHANGED
package/scripts/upgrade.ts
CHANGED
|
@@ -50,6 +50,12 @@ const MERGE_DIRS: string[] = [
|
|
|
50
50
|
// Claude project assets
|
|
51
51
|
'.claude/commands',
|
|
52
52
|
'.claude/skills',
|
|
53
|
+
// Vona Claude project assets
|
|
54
|
+
'vona/.claude/commands',
|
|
55
|
+
'vona/.claude/skills',
|
|
56
|
+
// Zova Claude project assets
|
|
57
|
+
'zova/.claude/commands',
|
|
58
|
+
'zova/.claude/skills',
|
|
53
59
|
];
|
|
54
60
|
|
|
55
61
|
const BLACKLIST_DIRS: string[] = [
|
|
@@ -2,7 +2,7 @@ import { z } from 'zod';
|
|
|
2
2
|
|
|
3
3
|
import { Metadata } from './metadata.ts';
|
|
4
4
|
import { isNil } from './utils.ts';
|
|
5
|
-
import { isZodType } from './zod-is-type.ts';
|
|
5
|
+
import { isNullableSchema, isZodType } from './zod-is-type.ts';
|
|
6
6
|
|
|
7
7
|
interface IParsePayload {
|
|
8
8
|
value: any;
|
|
@@ -33,6 +33,8 @@ function __parseAdapter(inst: z.ZodType, parse) {
|
|
|
33
33
|
return __parseObject(inst, parse, payload, _);
|
|
34
34
|
case 'array':
|
|
35
35
|
return __parseArray(inst, parse, payload, _);
|
|
36
|
+
case 'nullable':
|
|
37
|
+
return __parseNullable(inst, parse, payload, _);
|
|
36
38
|
case 'optional':
|
|
37
39
|
return __parseOptional(inst, parse, payload, _);
|
|
38
40
|
case 'default':
|
|
@@ -171,17 +173,27 @@ function __parseArray(_inst, parse, payload: IParsePayload, _) {
|
|
|
171
173
|
///////////////////////////////////////////
|
|
172
174
|
|
|
173
175
|
function __parseOptional(_inst, parse, payload: IParsePayload, _) {
|
|
174
|
-
|
|
175
|
-
|
|
176
|
-
|
|
177
|
-
_coerceWithNil(payload);
|
|
178
|
-
}
|
|
179
|
-
if (payload.value === null) {
|
|
176
|
+
const nullable = isNullableSchema(_inst);
|
|
177
|
+
_coerceNullable(_inst, payload, nullable);
|
|
178
|
+
if (payload.value === null && !nullable) {
|
|
180
179
|
payload.value = undefined;
|
|
181
180
|
}
|
|
182
181
|
return parse(payload, _);
|
|
183
182
|
}
|
|
184
183
|
|
|
184
|
+
////////////////////////////////////////////
|
|
185
|
+
////////////////////////////////////////////
|
|
186
|
+
/// /////// //////////
|
|
187
|
+
/// /////// ZodNullable /////////
|
|
188
|
+
/// /////// //////////
|
|
189
|
+
////////////////////////////////////////////
|
|
190
|
+
////////////////////////////////////////////
|
|
191
|
+
|
|
192
|
+
function __parseNullable(_inst, parse, payload: IParsePayload, _) {
|
|
193
|
+
_coerceNullable(_inst, payload, true);
|
|
194
|
+
return parse(payload, _);
|
|
195
|
+
}
|
|
196
|
+
|
|
185
197
|
////////////////////////////////////////////
|
|
186
198
|
////////////////////////////////////////////
|
|
187
199
|
/// /////// /////////
|
|
@@ -191,11 +203,7 @@ function __parseOptional(_inst, parse, payload: IParsePayload, _) {
|
|
|
191
203
|
////////////////////////////////////////////
|
|
192
204
|
|
|
193
205
|
function __parseDefault(_inst, parse, payload: IParsePayload, _) {
|
|
194
|
-
|
|
195
|
-
_coerceString(payload);
|
|
196
|
-
} else {
|
|
197
|
-
_coerceWithNil(payload);
|
|
198
|
-
}
|
|
206
|
+
_coerceNullable(_inst, payload, isNullableSchema(_inst));
|
|
199
207
|
return parse(payload, _);
|
|
200
208
|
}
|
|
201
209
|
|
|
@@ -225,6 +233,17 @@ function _coerceString(payload: IParsePayload, fn?: Function) {
|
|
|
225
233
|
}
|
|
226
234
|
}
|
|
227
235
|
|
|
236
|
+
function _coerceNullable(inst: z.ZodType, payload: IParsePayload, nullable: boolean) {
|
|
237
|
+
if (isZodType(Metadata.unwrapUntil(inst), 'ZodString')) {
|
|
238
|
+
_coerceString(payload);
|
|
239
|
+
if (nullable && payload.value === 'null') {
|
|
240
|
+
payload.value = null;
|
|
241
|
+
}
|
|
242
|
+
} else {
|
|
243
|
+
_coerceWithNil(payload);
|
|
244
|
+
}
|
|
245
|
+
}
|
|
246
|
+
|
|
228
247
|
function _coerceWithNil(payload: IParsePayload, fn?: Function) {
|
|
229
248
|
if (!isNil(payload.value)) {
|
|
230
249
|
if (payload.value === 'undefined' || payload.value === '') {
|
|
@@ -90,17 +90,59 @@ export function isAnyZodType(schema: object): schema is z.ZodType {
|
|
|
90
90
|
}
|
|
91
91
|
|
|
92
92
|
/**
|
|
93
|
-
* The schema.isNullable() is deprecated. This is the suggested replacement
|
|
94
|
-
* as this was how isNullable operated beforehand.
|
|
93
|
+
* The schema.isNullable() is deprecated. This is the suggested replacement.
|
|
95
94
|
*/
|
|
96
95
|
export function isNullableSchema(schema: z.ZodType) {
|
|
97
|
-
return schema
|
|
96
|
+
return _isNullableSchema(schema);
|
|
98
97
|
}
|
|
99
98
|
|
|
100
99
|
/**
|
|
101
|
-
* The schema.isOptional() is deprecated. This is the suggested replacement
|
|
102
|
-
* as this was how isOptional operated beforehand.
|
|
100
|
+
* The schema.isOptional() is deprecated. This is the suggested replacement.
|
|
103
101
|
*/
|
|
104
102
|
export function isOptionalSchema(schema: z.ZodType) {
|
|
105
|
-
return schema
|
|
103
|
+
return _isOptionalSchema(schema);
|
|
104
|
+
}
|
|
105
|
+
|
|
106
|
+
function _isNullableSchema(schema: z.ZodType): boolean {
|
|
107
|
+
if (isZodType(schema, 'ZodNullable')) return true;
|
|
108
|
+
if (isZodType(schema, 'ZodNonOptional')) return false;
|
|
109
|
+
if (
|
|
110
|
+
isZodType(schema, ['ZodOptional', 'ZodDefault', 'ZodReadonly']) &&
|
|
111
|
+
isAnyZodType(schema._zod.def.innerType)
|
|
112
|
+
) {
|
|
113
|
+
return _isNullableSchema(schema._zod.def.innerType);
|
|
114
|
+
}
|
|
115
|
+
if (isZodType(schema, 'ZodPipe')) {
|
|
116
|
+
const inSchema = schema._zod.def.in;
|
|
117
|
+
const outSchema = schema._zod.def.out;
|
|
118
|
+
if (isZodType(inSchema, 'ZodTransform') && isAnyZodType(outSchema)) {
|
|
119
|
+
return _isNullableSchema(outSchema);
|
|
120
|
+
}
|
|
121
|
+
if (isAnyZodType(inSchema)) {
|
|
122
|
+
return _isNullableSchema(inSchema);
|
|
123
|
+
}
|
|
124
|
+
}
|
|
125
|
+
return false;
|
|
126
|
+
}
|
|
127
|
+
|
|
128
|
+
function _isOptionalSchema(schema: z.ZodType): boolean {
|
|
129
|
+
if (isZodType(schema, ['ZodOptional', 'ZodDefault'])) return true;
|
|
130
|
+
if (isZodType(schema, 'ZodNonOptional')) return false;
|
|
131
|
+
if (
|
|
132
|
+
isZodType(schema, ['ZodNullable', 'ZodReadonly']) &&
|
|
133
|
+
isAnyZodType(schema._zod.def.innerType)
|
|
134
|
+
) {
|
|
135
|
+
return _isOptionalSchema(schema._zod.def.innerType);
|
|
136
|
+
}
|
|
137
|
+
if (isZodType(schema, 'ZodPipe')) {
|
|
138
|
+
const inSchema = schema._zod.def.in;
|
|
139
|
+
const outSchema = schema._zod.def.out;
|
|
140
|
+
if (isZodType(inSchema, 'ZodTransform') && isAnyZodType(outSchema)) {
|
|
141
|
+
return _isOptionalSchema(outSchema);
|
|
142
|
+
}
|
|
143
|
+
if (isAnyZodType(inSchema)) {
|
|
144
|
+
return _isOptionalSchema(inSchema);
|
|
145
|
+
}
|
|
146
|
+
}
|
|
147
|
+
return false;
|
|
106
148
|
}
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "vona",
|
|
3
|
-
"version": "5.1.
|
|
3
|
+
"version": "5.1.47",
|
|
4
4
|
"gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
|
|
5
5
|
"description": "Vona is an intuitive, elegant and powerful Node.js framework for rapidly developing enterprise applications of any size",
|
|
6
6
|
"keywords": [
|