typia 5.2.0 → 5.2.1
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/lib/executable/TypiaSetupWizard.js +13 -13
- package/lib/executable/TypiaSetupWizard.js.map +1 -1
- package/package.json +1 -1
- package/src/executable/TypiaSetupWizard.ts +15 -13
- package/src/factories/internal/metadata/emplace_metadata_object.ts +150 -150
- package/src/functional/$clone.ts +4 -4
- package/src/http.ts +1149 -1149
- package/src/json.ts +648 -648
- package/src/misc.ts +651 -651
- package/src/programmers/IsProgrammer.ts +252 -252
- package/src/programmers/TypiaProgrammer.ts +169 -169
- package/src/programmers/helpers/OptionPredicator.ts +15 -15
- package/src/programmers/json/JsonStringifyProgrammer.ts +964 -964
- package/src/protobuf.ts +887 -887
- package/src/transformers/ITransformOptions.ts +62 -62
|
@@ -1,62 +1,62 @@
|
|
|
1
|
-
export interface ITransformOptions {
|
|
2
|
-
/**
|
|
3
|
-
* Whether to validate finite number or not.
|
|
4
|
-
*
|
|
5
|
-
* If configured true, number typed values would be validated by Number.isNaN().
|
|
6
|
-
*
|
|
7
|
-
* However, whatever you configure, it would be ignored when marshaling or parsing.
|
|
8
|
-
*
|
|
9
|
-
* - when marshaling, always be true
|
|
10
|
-
* - assertStringify()
|
|
11
|
-
* - validateEncode()
|
|
12
|
-
* - when parsing, always be false
|
|
13
|
-
* - assertParse()
|
|
14
|
-
* - isDecode()
|
|
15
|
-
*
|
|
16
|
-
* @default false
|
|
17
|
-
*/
|
|
18
|
-
finite?: undefined | boolean;
|
|
19
|
-
|
|
20
|
-
/**
|
|
21
|
-
* Whether to validate finite number or not.
|
|
22
|
-
*
|
|
23
|
-
* If configured true, number typed values would be validated by Number.isFinite().
|
|
24
|
-
*
|
|
25
|
-
* However, whatever you configure, it can be ignored in below case.
|
|
26
|
-
*
|
|
27
|
-
* - when `finite` option is true, this option would be ignored
|
|
28
|
-
* - when marshaling, always be true
|
|
29
|
-
* - assertStringify()
|
|
30
|
-
* - validateEncode()
|
|
31
|
-
* - when parsing, always be false
|
|
32
|
-
* - assertParse()
|
|
33
|
-
* - isDecode()
|
|
34
|
-
*
|
|
35
|
-
* @default false
|
|
36
|
-
*/
|
|
37
|
-
numeric?: undefined | boolean;
|
|
38
|
-
|
|
39
|
-
/**
|
|
40
|
-
* Whether to validate functional type or not.
|
|
41
|
-
*
|
|
42
|
-
* However, whatever you configure, it becomes false when marshaling or parsing.
|
|
43
|
-
*
|
|
44
|
-
* @default false
|
|
45
|
-
*/
|
|
46
|
-
functional?: undefined | boolean;
|
|
47
|
-
|
|
48
|
-
/**
|
|
49
|
-
* Whether to check undefined value or not.
|
|
50
|
-
*
|
|
51
|
-
* JavaScript can assign `undefined` value to a specific property and it is an
|
|
52
|
-
* issue when validating without allowing superfluous properties. Should undefined
|
|
53
|
-
* value assigned superfluous property be allowed or not?
|
|
54
|
-
*
|
|
55
|
-
* Note that, this option only works on {@link equals} function. Other function
|
|
56
|
-
* like {@link assertEquals} or {@link validateEquals} would ignore this option
|
|
57
|
-
* value and always allow the `undefined` value.
|
|
58
|
-
*
|
|
59
|
-
* @default true
|
|
60
|
-
*/
|
|
61
|
-
undefined?: undefined | boolean;
|
|
62
|
-
}
|
|
1
|
+
export interface ITransformOptions {
|
|
2
|
+
/**
|
|
3
|
+
* Whether to validate finite number or not.
|
|
4
|
+
*
|
|
5
|
+
* If configured true, number typed values would be validated by Number.isNaN().
|
|
6
|
+
*
|
|
7
|
+
* However, whatever you configure, it would be ignored when marshaling or parsing.
|
|
8
|
+
*
|
|
9
|
+
* - when marshaling, always be true
|
|
10
|
+
* - assertStringify()
|
|
11
|
+
* - validateEncode()
|
|
12
|
+
* - when parsing, always be false
|
|
13
|
+
* - assertParse()
|
|
14
|
+
* - isDecode()
|
|
15
|
+
*
|
|
16
|
+
* @default false
|
|
17
|
+
*/
|
|
18
|
+
finite?: undefined | boolean;
|
|
19
|
+
|
|
20
|
+
/**
|
|
21
|
+
* Whether to validate finite number or not.
|
|
22
|
+
*
|
|
23
|
+
* If configured true, number typed values would be validated by Number.isFinite().
|
|
24
|
+
*
|
|
25
|
+
* However, whatever you configure, it can be ignored in below case.
|
|
26
|
+
*
|
|
27
|
+
* - when `finite` option is true, this option would be ignored
|
|
28
|
+
* - when marshaling, always be true
|
|
29
|
+
* - assertStringify()
|
|
30
|
+
* - validateEncode()
|
|
31
|
+
* - when parsing, always be false
|
|
32
|
+
* - assertParse()
|
|
33
|
+
* - isDecode()
|
|
34
|
+
*
|
|
35
|
+
* @default false
|
|
36
|
+
*/
|
|
37
|
+
numeric?: undefined | boolean;
|
|
38
|
+
|
|
39
|
+
/**
|
|
40
|
+
* Whether to validate functional type or not.
|
|
41
|
+
*
|
|
42
|
+
* However, whatever you configure, it becomes false when marshaling or parsing.
|
|
43
|
+
*
|
|
44
|
+
* @default false
|
|
45
|
+
*/
|
|
46
|
+
functional?: undefined | boolean;
|
|
47
|
+
|
|
48
|
+
/**
|
|
49
|
+
* Whether to check undefined value or not.
|
|
50
|
+
*
|
|
51
|
+
* JavaScript can assign `undefined` value to a specific property and it is an
|
|
52
|
+
* issue when validating without allowing superfluous properties. Should undefined
|
|
53
|
+
* value assigned superfluous property be allowed or not?
|
|
54
|
+
*
|
|
55
|
+
* Note that, this option only works on {@link equals} function. Other function
|
|
56
|
+
* like {@link assertEquals} or {@link validateEquals} would ignore this option
|
|
57
|
+
* value and always allow the `undefined` value.
|
|
58
|
+
*
|
|
59
|
+
* @default true
|
|
60
|
+
*/
|
|
61
|
+
undefined?: undefined | boolean;
|
|
62
|
+
}
|