Thinking About Forking revalidator

Tuesday, May 6th 2014

When it first came out, I was a really big fan of flatiron. I made some contributions to some of the packages in flatiron. That was fun and nice. However, the more I used it, the less I agreed with its opinions. No big deal, right? Either suck it up and drive on or move onto another library or write your own.

That’s the way of open-source software. I like that ecosystem.

I still really like two of the flatiron libraries:

cradle
A high-level, caching, CouchDB client for Node.js
revalidator
A cross-browser / node.js validator used by resourceful and flatiron. Revalidator has JSONSchema compatibility as primary goal.

I don’t use cradle because I wrote stork. No problem.

What does revalidator do?

There’s this cool spec called JSON Schema which does for JSON what schemas do for XML. In other words, it provides a description of the type of information found in a JSON payload. That’s nice.

revalidator creates a library that mimics the JSON Schema specification to validate objects rather than JSON-formatted documents. That’s even nicer.

Let’s say I want to have an object that has a required firstName property, a required lastName property that must have a length longer than 3 characters (sorry, Jennifer Wu!), and an optional numeric age property, then I can use revalidator to express those expectations with the following code.

1
2
3
4
5
6
7
8
9
10
11
12
13
var revalidator, schema;
revalidator = require('revalidator'),
schema = {
properties: {
firstName: { type: 'string', required: true },
lastName: { type: 'string', required: true, minLength: 3 },
age: { type: 'integer' }
}
};

function validateObject(o) {
return revalidator.validate(o, schema);
}

The return value of the validate call returns an object like this:

1
2
3
4
{
valid: true // or false
errors: [/* Array of errors if valid is false */]
}

That’s awesome. It solves all my problems!

It doesn’t really solve all of my problems

I’ve used revalidator in a couple of projects, now. But, with my work on stork, I need something beyond the possibilities of revalidator. So, I have one of two options, here.

  1. Write my own validation library; or,
  2. Fork revalidator, make it extensible, and give back.

I think the second option wins hands down. The authors of revalidator have done a really good job at writing clear and concise code. Thank you, flatiron guys!

I guess that’s what I’m going to do.

Yep, that’s what I did

And, now I’ve done it. If you want to help out with the refactoring of revalidator to support more validations, do the GitHub thing: fork, write, test, pull request.