Rename `inp()` to a More Descriptive Name for Clarity

[GroophyLifefor]

Problem

Currently, Yelix's validation system uses inp() as the function to define validation rules. While inp is short for "input," it may not be intuitive for all users. Additionally, since Yelix may support output validation in the future, having a clearer name would improve readability and maintainability.

Proposed Solution

Rename inp() to a more descriptive and intuitive name, such as:

• input() – Explicitly refers to input validation.
• validate() – Aligns with the purpose of defining validation rules.
• field() – Emphasizes defining a field's validation.

Current Usage:

export const validation: ValidationType = {
  query: {
    page: inp().number().integer().min(1).optional(),
    limit: inp().number().integer().range(1, 100),
    isActive: inp().boolean().transform()
  },
  body: inp().object({
    username: inp().string().min(3).max(255),
    email: inp().string().email(),
  })
};

[GroophyLifefor]

Name	Pros	Cons/Notes
schema()	- ✅ Universal for both input and output validation. - ✅ Common in other libraries (Zod, Joi). - ✅ Clear and descriptive.	- ⚠️ Longer name, can be cumbersome when used frequently. - ⚠️ May feel too generic or broad.
define()	- ✅ Neutral and flexible. - ✅ Expresses intent of defining validation rules. - ✅ Modern and readable.	- ⚠️ Slightly longer than others, might feel less intuitive in certain cases.
type()	- ✅ Works for both input and output. - ✅ Short and clear. - ✅ Great for TypeScript-heavy environments.	- ⚠️ Could be confused with TypeScript's type keyword. - ⚠️ Less intuitive for some users.
spec()	- ✅ Short for "specification". - ✅ Good for expressing validation rules. - ✅ Unique and catchy.	- ⚠️ Less commonly used; might take a while to get used to. - ⚠️ Could feel more niche.
field()	- ✅ Short and intuitive for field validation. - ✅ Strong for nested structures. - ✅ Clear when used for object properties.	- ⚠️ Not ideal for root-level validation. - ⚠️ Might feel odd when used for top-level validation.
value()	- ✅ Strong for defining field types (primitives). - ✅ Clear for simple fields.	- ⚠️ Might sound awkward for complex structures like objects or arrays.
constraint()	- ✅ Explicitly describes validation rules. - ✅ Clear and precise for complex validations.	- ⚠️ Might feel a bit verbose for frequent use. - ⚠️ Could feel overly technical for some.
rule()	- ✅ Short and clear. - ✅ Intuitive. - ✅ Works well for both input/output. - ✅ Flexible and broad.	- ⚠️ Might feel slightly abstract for some complex objects. - ⚠️ Less descriptive for complex structures.
check()	- ✅ Short and intuitive. - ✅ Common in other validation contexts. - ✅ Flexible for input/output.	- ⚠️ Might be confused with conditional checks in logic (e.g., if statements).

[mertssmnoglu]

I vote for schema(), it's highly used in software development and is easy to remember.

[1m1ssher]

Great discussion about improving API clarity! I'd vote for validate() as the function name for several reasons:

Why validate() is the best choice:

1. Universal Understanding: "Validate" is universally understood across programming languages and frameworks
2. Future-Proof: Works well even if you expand beyond input validation (as mentioned, output validation could be validateOutput())
3. Self-Documenting: Code becomes more readable: validate().string().email() vs inp().string().email()
4. Framework Consistency: Popular validation libraries like Joi, Yup, and Zod use similar naming patterns

Alternative implementation consideration:

// Current
inp().string().min(3)

// Proposed 
validate().string().min(3)

// Or even more descriptive
field().string().min(3)  // emphasizes this defines a field's constraints

The validate() naming aligns with established patterns while being immediately clear about the function's purpose. What do you think about this approach?

[GroophyLifefor]

Hi @wh1sky02, thank you for sharing you idea. we are moved to an more difficult but more flexible idea that wrapping tools. like https://github.com/yelix-cloud/js-hono-zod-validator . It's have same usage as base tool but with metadata wrapped system. It's a little different approach rather than so much others but we are working on that to be best way for developers.