Super-fast/easy runtime validations and serializations through transformation
MIT License
Bot releases are visible (Hide)
Published by samchon 12 months ago
Record<string & tags.Format<"uuid">, T>
case. by @samchon in https://github.com/samchon/typia/pull/861
Full Changelog: https://github.com/samchon/typia/compare/v5.2.4...v5.2.5
Published by samchon 12 months ago
Full Changelog: https://github.com/samchon/typia/compare/v5.2.3...v5.2.4
Published by samchon about 1 year ago
npx typia setup
. by @samchon in https://github.com/samchon/typia/pull/847
Full Changelog: https://github.com/samchon/typia/compare/v5.2.2...v5.2.3
Published by samchon about 1 year ago
When JSON.stringify()
function be called about Map<Key, T>
type, it always returns the empty bracket value {}
. Until now, I'd developed typia
to return the empty bracket value {}
, following the standard JSON.stringify()
function.
However, as most TypeScript/JavaScript developers do not know about that and there's not any problem when using the Map
type on typia.json.stringify<T>()
function ini the compile time, it was possible to misunderstand that typia
's stringify function has a bug about the Map
time.
In such reason, I've decided to throw a compile error when such non-supported type being used in the typia.json
functions. Also, such strategy would be helpful for typia
users to avoid taking a mistake using such non-supported type on the JSON functions.
Full Changelog: https://github.com/samchon/typia/compare/v5.2.1...v5.2.2
Published by samchon about 1 year ago
To support yarn berry
which had banned npm prepare
script, I'd changed setup wizard of typia
to define npm postinstall
script instead.
By the way, unlike the npm prepare
script which works on only in the local drive and does not work when be installed from remote npm
, npm postinstall
script is working even when installing from the remote npm
. Therefore, when publishing an npm
module which has installed tyipa
through setup wizard, it enforces users of derived libraries to run the npm postinstall
command that requires ts-patch
module.
To fix this crazy bug, I've decided to ban yarn berry
on the setup wizard. From now on, when you run the npx typia setup
command, it will print a text that "yarn berry is not supported". If you still want to utilize the yarn berry
, configure it manually by yourself please.
yarn berry
on setup wizard. by @samchon in https://github.com/samchon/typia/pull/840
Full Changelog: https://github.com/samchon/typia/compare/v5.2.0...v5.2.1
Published by samchon about 1 year ago
Added a new module notations
to support naming convention converters.
This update is for future's nestia feature.
export namespace notations {
export function camel<T>(input: T): CamelCase<T>;
export function assertCamel<T>(input: unknown | T): CamelCase<T>;
export function isCamel<T>(input: unknown | T): CamelCase<T> | null;
export function validateCamel<T>(input: unknown | T): IValidation<CamelCase<T>>;
export function pascal<T>(input: T): PascalCase<T>;
export function assertPascal<T>(input: unknown | T): PascalCase<T>;
export function isPascal<T>(input: unknown | T): PascalCase<T> | null;
export function validatePascal<T>(input: unknown | T): IValidation<PascalCase<T>>;
export function snake<T>(input: T): SnakeCase<T>;
export function assertSnake<T>(input: unknown | T): SnakeCase<T>;
export function isSnake<T>(input: unknown | T): SnakeCase<T> | null;
export function validateSnake<T>(input: unknown | T): IValidation<SnakeCase<T>>;
}
notations
, the naming convention converters by @samchon in https://github.com/samchon/typia/pull/835
Full Changelog: https://github.com/samchon/typia/compare/v5.1.6...v5.2.0
Published by samchon about 1 year ago
@sinclair/typebox
to devDependencies
by @techvlad in https://github.com/samchon/typia/pull/832
Full Changelog: https://github.com/samchon/typia/compare/v5.1.5...v5.1.6
Published by samchon about 1 year ago
New module http
has been newly added.
export namespace http {
export function parameter<T extends boolean | bigint | number | string>(input: string): T;
export function headers<T extends object>(input: Record<string, string | string[] | undefined>): Resolved<T>;
export function isHeaders<T extends object>(input: Record<string, string | string[] | undefined>): Resolved<T> | null;
export function assertHeaders<T extends object>(input: Record<string, string | string[] | undefined>): Resolved<T>;
export function validateHeaders<T extends object>(input: Record<string, string | string[] | undefined>): IValidation<Resolved<T>>;
export function query<T extends object>(input: URLSearchParams): Resolved<T>;
export function isQuery<T extends object>(input: URLSearchParams): Resolved<T> | null;
export function assertQuery<T extends object>(input: URLSearchParams): Resolved<T>;
export function validateQuery<T extends object>(input: URLSearchParams): IValidation<Resolved<T>>;
}
For reference, those features had been developed in @nestia/core
for a long time.
The reason why migrating them from @nestia/core
is to support Fastify
plugin like nestia
case. In the same reason, I've changed naming strategy of JSON schema (IJsonComponents
) to be much simpler.
Also, fixed a bug occurred only when tsconfig.json
has configured exactOptionalPropertyTypes
option and utilizing Partial<T>
and Required<T>
types.
http
- query
, headeres
and parameter
by @samchon in https://github.com/samchon/typia/pull/819
Default
. by @samchon in https://github.com/samchon/typia/pull/821
exactOptionalPropertyTypes
's with Partial<T>
and Required<T>
types. by @samchon in https://github.com/samchon/typia/pull/829
Full Changelog: https://github.com/samchon/typia/compare/v5.0.5...v5.1.5
Published by samchon about 1 year ago
Full Changelog: https://github.com/samchon/typia/compare/v5.1.3...v5.1.4
Published by samchon about 1 year ago
New module http
has been newly added.
export namespace http {
export function parameter<T extends boolean | bigint | number | string>(input: string): T;
export function headers<T extends object>(input: Record<string, string | string[] | undefined>): Resolved<T>;
export function isHeaders<T extends object>(input: Record<string, string | string[] | undefined>): Resolved<T> | null;
export function assertHeaders<T extends object>(input: Record<string, string | string[] | undefined>): Resolved<T>;
export function validateHeaders<T extends object>(input: Record<string, string | string[] | undefined>): IValidation<Resolved<T>>;
export function query<T extends object>(input: URLSearchParams): Resolved<T>;
export function isQuery<T extends object>(input: URLSearchParams): Resolved<T> | null;
export function assertQuery<T extends object>(input: URLSearchParams): Resolved<T>;
export function validateQuery<T extends object>(input: URLSearchParams): IValidation<Resolved<T>>;
}
For reference, those features had been developed in @nestia/core
for a long time.
The reason why migrating them from @nestia/core
is to support Fastify
plugin like nestia
case. Also, in the same reason, I've changed naming strategy of JSON schema (IJsonComponents
) to be much simpler.
http
- query
, headeres
and parameter
by @samchon in https://github.com/samchon/typia/pull/819
Default
. by @samchon in https://github.com/samchon/typia/pull/821
Full Changelog: https://github.com/samchon/typia/compare/v5.0.5...v5.1.3
Published by samchon about 1 year ago
New module http
has been newly added.
export namespace http {
export function parameter<T extends boolean | bigint | number | string>(input: string): T;
export function headers<T extends object>(input: Record<string, string | string[] | undefined>): Resolved<T>;
export function isHeaders<T extends object>(input: Record<string, string | string[] | undefined>): Resolved<T> | null;
export function assertHeaders<T extends object>(input: Record<string, string | string[] | undefined>): Resolved<T>;
export function validateHeaders<T extends object>(input: Record<string, string | string[] | undefined>): IValidation<Resolved<T>>;
export function query<T extends object>(input: URLSearchParams): Resolved<T>;
export function isQuery<T extends object>(input: URLSearchParams): Resolved<T> | null;
export function assertQuery<T extends object>(input: URLSearchParams): Resolved<T>;
export function validateQuery<T extends object>(input: URLSearchParams): IValidation<Resolved<T>>;
}
For reference, those features had been developed in @nestia/core
for a long time.
The reason why migrating them from @nestia/core
is to support Fastify
plugin like nestia
case.
http
- query
, headeres
and parameter
by @samchon in https://github.com/samchon/typia/pull/819
Full Changelog: https://github.com/samchon/typia/compare/v5.0.5...v5.1.1
Published by samchon about 1 year ago
From now on, generation mode supports *.tsx
files.
*.tsx
files' generation by @samchon in https://github.com/samchon/typia/pull/817
Full Changelog: https://github.com/samchon/typia/compare/v5.0.4...v5.0.5
Published by samchon about 1 year ago
Full Changelog: https://github.com/samchon/typia/compare/v5.0.3...v5.0.4
Published by samchon about 1 year ago
Full Changelog: https://github.com/samchon/typia/compare/v5.0.2...v5.0.3
Published by samchon about 1 year ago
noUncheckedIndexedAccess
option. by @samchon in https://github.com/samchon/typia/pull/805
Full Changelog: https://github.com/samchon/typia/compare/v5.0.1...v5.0.2
Published by samchon about 1 year ago
Full Changelog: https://github.com/samchon/typia/compare/v5.0.0...v5.0.1
Published by samchon about 1 year ago
https://typia.io/docs/protobuf/message/
Typia v5 supports Protocol Buffer functions.
Lots of TypeScript users had requested this feature, and I've implemented.
@lemon-mint helped me a lot, and repository as-proto
(of @piotr-oles) was great to reference.
Now, let's encode to protocol buffer binary data with only one line function call, as always we've done.
export namespace protobuf {
export function message<T>(): string; // Protocol Buffer message
export function assertDecode<T>(buffer: Buffer): T; // safe decoder
export function assertEncode<T>(input: T): Uint8Array; // safe encoder
}
https://typia.io/docs/validators/tags/
Typia v5 supports new type tags for custom validation.
From now on, making custom validation logic is much easier and safer than before.
import typia, { tags } from "typia";
export const checkSomething = typia.createIs<Something>();
//----
// DEFINE CUSTOM TYPE TAGS
//----
type Dollar = tags.TagBase<{
kind: "dollar";
target: "string";
value: undefined;
validate: `$input[0] === "$" && !isNaN(Number($input.substring(1).split(",").join("")))`;
}>;
type Postfix<Value extends string> = tags.TagBase<{
kind: "postfix";
target: "string";
value: Value;
validate: `$input.endsWith("${Value}")`;
}>;
type IsEven<Value extends number | bigint> = tags.TagBase<{
kind: "isEven";
target: Value extends number ? "number" : "bigint";
value: undefined;
validate: `$input % ${Numeric<2>} === ${Numeric<0>}`;
}>;
type Numeric<Value extends number | bigint> = Value extends number
? Value
: `BigInt(${Value})`;
https://typia.io/docs/protobuf/message/#restrictions
When user tries to call typia
function with unsupported type like bigint
type for JSON functions, typia
had occured exception that kills TypeScript compiler, even when running tsc --watch
command. It was not a critical problem, because except bigint
type, functions in typia
supported every TypeScript type.
However, as typia
starts supporting Protocol Buffer functions in v5 update, and expression power of Protocol Buffer is extremely narrower than TypeScript type specs. User may try many types in Protocol Buffer functions, and gradually fix their TypeScript types referencing error message from typia
. In that circumstance, if typia
kills tsc --watch
command whenever unsupported type comes, it would be a great annoying problem for users.
Therefore, I've changed typia
to create compilation error instead of throwing exception. From now on, whenever you take a mistake on typia
functions with unsupported types, it would be a compilation error, and would be printed on your console like below
main.ts:13:1 - error TS(typia.protobuf.message): unsupported type detected
- Something.any: any
- does not support any type
- Something.unknown: any
- does not support any type
- Something.closure: unknown
- does not support functional type
- Something.dict: (Set<string> | WeakMap | WeakSet)
- does not support Set type
- does not support WeakSet type. Use Array type instead.
- does not support WeakMap type. Use Map type instead.
- Something.date: Date
- does not support Date type. Use string type instead.
- Something.classic: String
- does not support String type. Use string type instead.
- Something.buffer: ArrayBuffer
- does not support ArrayBuffer type. Use Uint8Array type instead.
As type system of Protocol Buffer is extremely different with TypeScript (expression power of Protocol Buffer is much lower than TypeScript), I had to develop much more test programs. Especially, to support restrictions of Protocol Buffer types, I've added a new genre of test programs that simulating compilation errors that must be happened.
As a result of such development, LOC of test programs are reaching to 1,400,000. It was a hard time for me, but of that, I believe that users of typia
can use it with more confidence. From now on, my slogan is "The word best validator library ensured by 1.4M LOC test codes.". You typia
users, as almost all types of TypeScript are rigorously verified with a test program, just use it with confidence.
random()
functionUntil v4 version, typia.random<T>()
function could not generate bigint
or Uint8Array
type, because it had been designed for JSON data, especially for RestAPI backend environments (I'd used it for mockup simulator generator - https://nestia.io/docs/sdk/simulator/). By the way, as v5 version starts supporting Protocol Buffer features, I've also advanced typia.random<T>()
function.
Therefore, return type of typia.random<T>()
function has been changed from Primitive<T>
type to Resolved<T>
to support bigint
and Uint8Array
types. Also, as v5 version of typia
supports advanced custom validation feature, typia.random<T>()
function also changed its custom random data generation interface to be much efficient.
// RUNTIME VALIDATORS
export function is<T>(input: unknown): input is T; // returns boolean
export function assert<T>(input: unknown): T; // throws TypeGuardError
export function validate<T>(input: unknown): IValidation<T>; // detailed
// JSON FUNCTIONS
export namespace json {
export function application<T>(): IJsonApplication; // JSON schema
export function assertParse<T>(input: string): T; // type safe parser
export function assertStringify<T>(input: T): string; // safe and faster
}
// PROTOCOL BUFFER
export namespace protobuf {
export function message<T>(): string; // Protocol Buffer message
export function assertDecode<T>(buffer: Buffer): T; // safe decoder
export function assertEncode<T>(input: T): Uint8Array; // safe encoder
}
// RANDOM GENERATOR
export function random<T>(g?: Partial<IRandomGenerator>): T;
As typia
has started supporting Protocol Buffer, and planning to support much more binary related protocols like CBOR
and MessagePack
(https://github.com/samchon/typia/issues/514), I've wrapped JSON related functions into a json
namespace. Also, Protocol Buffer functions are capsuled into the protobuf
namespace.
I'm sorry for users about such critical changes, but I believe you can easily adjust to it. Also, such namespace wrapping would make typia
much efficient especially for extensionability in future.
https://typia.io/docs/validators/tags/#comment-tags
Until v4 version, comment tags could be adjusted to a element (value) type of Array
and Map
.
However, since v5 version, comment tags only be applied to the target type.
TSON.message()
by @samchon in https://github.com/samchon/typia/pull/391
ts-proto
by @samchon in https://github.com/samchon/typia/pull/470
typia.protobuf.message<T>()
function. by @samchon in https://github.com/samchon/typia/pull/756
typia.protobuf.encode()
functions by @samchon in https://github.com/samchon/typia/pull/765
tyipa.protobuf.decode<T>()
functions by @samchon in https://github.com/samchon/typia/pull/776
typia.protobuf.encode<T>()
functions for complicate union types by @samchon in https://github.com/samchon/typia/pull/778
typia.random<T>()
and typia.misc.clone<T>()
functions. by @samchon in https://github.com/samchon/typia/pull/779
Full Changelog: https://github.com/samchon/typia/compare/v4.3.3...v5.0.0
Published by samchon about 1 year ago
Full Changelog: https://github.com/samchon/typia/compare/v4.3.2...v4.3.3
Published by samchon about 1 year ago
From v4.3 update, below type comment tags being supported.
Also, in the bigint
case, it can use @type uint64
comment tag for unsigned bigint
restriction.
For reference, such type comment tags are designed to prepare the next v5 update, Protocol Buffer supporting.
@type {string}
int
/ int32
: -2^31 <= x <= 2^31 - 1
uint
/ uint32
: 0 <= x <= 2^32 - 1
uint64
: 0 <= x <= 2^64 - 1
int64
: -2^63 <= x <= 2^63 - 1
float
: -1.175494351e38 <= x <= 3.4028235e38
@type int/uint
comment tags. by @samchon in https://github.com/samchon/typia/pull/770
@type int/uint
must not be adjusted to bigint
type. by @samchon in https://github.com/samchon/typia/pull/771
Full Changelog: https://github.com/samchon/typia/compare/v4.2.3...v4.3.2
Published by samchon about 1 year ago
MetadataFactory
. by @samchon in https://github.com/samchon/typia/pull/761
Full Changelog: https://github.com/samchon/typia/compare/v4.2.2...v4.2.3