@validatem/error

This package contains the ValidationError type for validatem.

A VERY IMPORTANT NOTE: You should always use the caret notation (eg. ^1.0.0) when depending on this package. NPM and Yarn will do this by default when you npm install @validatem/error or yarn add @validatem/error, but some people turn this off - don't do that here, or things might break!

Why is this a separate package?

Because it makes forwards compatibility easier. Even if @validatem/core ever needs a breaking release, chances are that the error format remains unchanged. Making the error type separately versionable, means that in that scenario validators should stay compatible with both the old and the new version of the core, without validator authors needing to update anything.

License, donations, and other boilerplate

Licensed under either the WTFPL or CC0, at your choice. In practice, that means it's more or less public domain, and you can do whatever you want with it. Giving credit is not required, but still very much appreciated! I'd love to hear from you if validatem was useful to you.

Creating and maintaining open-source modules is a lot of work. A donation is also not required, but much appreciated! You can donate here.

API

new ValidationError(message, [properties])

The constructor for validatem's ValidationError type. This is invoked like any other Error constructor, but you may optionally pass extra metadata that should be stored on the error.

Note that, for performance reasons (preventing stacktrace collection), the returned object does not actually inherit from Error! This should not affect its correct functioning, considering that the stacktraces of individual validators are not used in Validatem, and ValidationErrors should never be thrown outside of a validator context anyway.

Unless you are implementing a parser and using virtual properties, you probably do not need to specify the path property. Combinators like arrayOf will insert their path segments after-the-fact by themselves, your validator does not need to do this.

• message: A description of the validation problem. This should be formatted in such a way that it describes the requirement, and not how it failed; for example, it should say "Must be a string" rather than "Is not a string".
• properties: Optional. An object of properties to attach to the new error object.
  • path: An array of 'path segment' strings that describes the location of the validation error.

Changelog

v1.0.0 (April 20, 2020)

Initial release.