Creating a validation wrapper extending valibot schemas with additional actions

[imolorhe]

Hey! 👋🏾 I'm working on a project that uses valibot for validating input and output data based on a schema. I'm able to specify the type as GenericSchema for the schema which allows any valibot schema to be used. However for my project, I want to add additional custom checks/actions to the regular valibot schemas. For example, validating that strings don't contain a specific substring, or numbers follow an expected pattern, etc. Even for schemas that don't need any additional checks (yet), I want to create a wrapping schema for them and require the use of the project schemas instead of the regular valibot schemas. That is, using schemas (object(), string(), number(), etc) from valibot should show a typescript error and a runtime error and require the use of equivalent schemas with the additional validations from the project instead.

Is there a way to achieve this without having to re-implement the schemas and parsers already implemented in valibot?

[imolorhe]

Hmm, maybe brand is what I'm looking for?

[imolorhe]

Okay looks like that just affects the output type.

[fabian-hiller]

You can extend the validation of an existing schema using our pipe method:

import * as v from 'valibot';

const EmailSchema = v.pipe(v.string(), v.email());
const GmailSchema = v.pipe(EmailSchema, v.endsWith('@gmail.com'));

And here is an example that shows how you can only allow specific schemas as arguments when using TypeScript:

import * as v from 'valibot';

const EmailSchema = v.pipe(v.string(), v.email());
type  EmailSchema = typeof EmailSchema;

const LoginSchema = v.object({
  email: EmailSchema,
  password: v.pipe(v.string(), v.minLength(8)),
});
type LoginSchema = typeof LoginSchema;

function foo(schema: EmailSchema | LoginSchema) {
  console.log(schema);
}

foo(EmailSchema); // Works
foo(v.string()); // Error

[fabian-hiller]

I would say that it depends on the use case.

[imolorhe]

Fair enough, but would like to verify that the approach of modifying schemas is fine and I'm not missing some other parts of the schema that need to be updated

[fabian-hiller]

People rarely modify the schema object, but we do it internally, for example with pick and omit. So Valibot is written with this in mind.

[imolorhe]

Thanks! Sounds good to me!

[fabian-hiller]

It's more likely to make mistakes if you do, and we don't expect external people to do it either. That's why every schema property is marked read-only, but in practice it should work in most cases. So if you know what you are doing it should be fine.

[imolorhe]

@fabian-hiller For my use case, I decided to go a different route where I modify the schema based on the value in the metadata action I find. This removes the need for context based runtime validation, and instead I want to modify the schema based on the context, which should mean better performance (since the additional context-based logic isn't executed at runtime). I am following a similar pattern used in getDefaults and getFallbacks to iterate over all the schemas in the schema. When I find a metadata value, I decide to either keep the schema or delete it from the schema object.

This appears to be working, when I parse some data using the modified schema, the dropped fields don't get returned. However I'm not sure if this is a supported pattern that could lead to unexpected behaviors, or if there's a different approach I should be taking here. For example, something I would like to do is add additional actions as well which I think I can achieve by creating a schema.pipe list (if it doesn't already exist) with the additional actions, but it feels like I'm working off of internal APIs

[fabian-hiller]

If you correctly work with our external API this is totally fine. Feel free to provide us feedback if there is anything we can do better.

[imolorhe]

Here's an example of what I have

export function getModifiedSchema(schema) {
  if ('pipe' in schema) {
    const metadataAction = schema.pipe.find(item => item.type === 'metadata');
    
    if (metadataAction?.metadata.allowed) {
      return schema;
    }
    
    if (metadataAction?.metadata.checkSecret) {
      // haven't tested this one, but this is something else I'd likely be doing..
      schema.pipe.push(v.check(
        (input) => typeof input === 'string' && !input.includes('secret_value'),
        'The item cannot have the secret value'
      ));
      return schema;
    }
  }
  
  return undefined;
}

export function getModifiedSchemas(schema) {
  // If it is an object schema, return defaults of entries
  if ('entries' in schema) {
    Object.entries(schema.entries).forEach(([key, value]) => {
      const modifiedSchema = getModifiedSchemas(value);
      if (!modifiedSchema) {
        Reflect.deleteProperty(schema.entries, key);
      }
    });
    return schema;
  }

  // If it is a tuple schema, return defaults of items
  if ('items' in schema) {
    return schema.items.map(getDefaults).filter(Boolean);
  }

  return getModifiedSchema(schema);
}

The schema can either be deleted or modified