feat(validator): Add type validator constraint

[EmanFateen]

Overview

In this PR, I have introduced new validation constraint called type.

type TypeOptions = ConstraintOptions & {
  type: AllowedTypes | AllowedTypes[];
  message?: string;
};

export type AllowedTypes =
  | 'string'
  | 'number'
  | 'boolean'
  | 'bigint'
  | 'symbol'
  | 'function'
  | 'object'
  | 'array'
  | 'null';

It's exposed through the builtInConstraints and can be used like

const rules = {
  age: [{ type: { type: 'number' } }],
  identifier: [{ type: { type: ['string', 'number'] } }],
}

• Main purpose of this constraint is to validate whether the given value matches the expected type or one of the expected types.
• This constraint is concerned about the type of the given value and should work as a required constraint, which means is the value is undefined the constraint will return no violations.
• Last point doesn't applied for the null as null is a real value.

Changes made:

1. Added the type constraint under basic constraint.
2. Covered the required cases in type.test file.
3. Exposed the type constraint through the builtInConstraints object.

Q	A
License	GPLv3
Issue	Closes #169 >

[imdhemy]

This PR introduces regression to the validator component’s structure. We’ve already improved the structure in #175. Could you kindly modify the changes here to align with the updated structure? @EmanFateen

I was reviewing an older version of the PR.

[imdhemy]

@EmanFateen
Thanks for moving this forward. The implementation is good and covers the issue, we just need to tighten the types and simplify the implementation.

[imdhemy]

This case is already covered in the test cases, but it’s better to have a separate test case for it, similar to how we did for the email constraint. This approach clearly communicates the intended behavior.

[EmanFateen]

Done.

[imdhemy]

A single test case with a clear intention is sufficient. For example, “it should bypass undefined value.”

You’ve added two test cases with different descriptions of behavior.

https://github.com/EmanFateen/framework/blob/d120ee5c1b643da1101e7b399e83b0ab1a726837/src/validator/constraints/basic/type.test.ts#L64

https://github.com/EmanFateen/framework/blob/d120ee5c1b643da1101e7b399e83b0ab1a726837/src/validator/constraints/basic/type.test.ts#L115

[EmanFateen]

I kept returns no violations for undefined value and removed the redundant one.
I see returns no violations for undefined value more clear than “it should bypass undefined value.”

Done

[imdhemy]

Since you’ve already declared types as an array, there’s no need to perform the check.

[imdhemy]

A single test case with a clear intention is sufficient. For example, “it should bypass undefined value.”

You’ve added two test cases with different descriptions of behavior.

https://github.com/EmanFateen/framework/blob/d120ee5c1b643da1101e7b399e83b0ab1a726837/src/validator/constraints/basic/type.test.ts#L64

https://github.com/EmanFateen/framework/blob/d120ee5c1b643da1101e7b399e83b0ab1a726837/src/validator/constraints/basic/type.test.ts#L115

[imdhemy]

@EmanFateen
Thank you!

I made ConstraintOptions generic so generic schema code can stay flexible, while specific constraints can keep precise option shapes. The old index signature leaked into every constraint-specific options type; now only the default generic form is loose, and ConstraintOptions<{ ... }> keeps custom constraint options strict while still sharing groups.