Validatem

An ergonomic and modular validation system for Javascript code - argument validation, arbitrary value validation, everything.

What is Validatem?

This article is derived from the documentation at https://www.npmjs.com/package/@validatem/core.

The last validation library you'll ever need.

While Validatem is suitable for any sort of validation, this unique combination of features and design choices makes it especially useful for validating arguments in the public API of libraries, unlike other validation libraries!

For example, you might write something like the following (from the icssify library):

module.exports = function (browserify, options) {
	validateArguments(arguments, {
		browserify: required,
		options: allowExtraProperties({
			mode: oneOf([ "local", "global" ]),
			before: arrayOf([ required, isPostcssPlugin ]),
			after: arrayOf([ required, isPostcssPlugin ]),
			extensions: arrayOf([ required, isString ])
		})
	});

	// Implementation code goes here ...
};

And calling it like so:

icssify(undefined, {
	mode: "nonExistentMode",
	before: [ NaN ],
	unspecifiedButAllowedOption: true
})

... would then produce an error like this:

ValidationError: One or more validation errors occurred:
 - At browserify: Required value is missing
 - At options -> mode: Must be one of: 'local', 'global'
 - At options -> before -> 0: Must be a PostCSS plugin

Why are there so many packages?

This article is derived from the documentation at https://www.npmjs.com/package/@validatem/core.

Dependencies often introduce a lot of unnecessary complexity into a project. To avoid that problem, I've designed Validatem to consist of a lot of small, separately-usable pieces - even much of the core plumbing has been split up that way, specifically the bits that may be used by validator and combinator functions.

This may sound counterintuitive; doesn't more dependencies mean more complexity? But in practice, "a dependency" in and of itself doesn't have a complexity cost at all; it's the code that is in the dependency where the complexity lies. The bigger a dependency is, the more complexity there is in that dependency, and the bigger the chance that some part of that complexity isn't even being used in your project!

By packaging things as granularly as possible, you end up only importing code into your project that you are actually using. Any bit of logic that's never used, is somewhere in a package that is never even installed. As an example: using 10 modules with 1 function each, will add less complexity to your project than using 1 module with 100 functions.

This has a lot of benefits, for both you and me:

Of course, there being so many packages means it can be more difficult to find the specific package you want. That is why the Validatem website has an extensive, categorized list of all the validators, combinators and utilities available for Validatem. Both officially-maintained ones, and third-party modules!