You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
Sven Slootweg 73838db4b5 Don't actually construct real Errors with stacktraces, for performance reasons 4 years ago
.gitignore Initial commit; v1.0.0 5 years ago
README.md Initial commit; v1.0.0 5 years ago
index.js Don't actually construct real Errors with stacktraces, for performance reasons 4 years ago
package.json Don't actually construct real Errors with stacktraces, for performance reasons 4 years ago
yarn.lock Initial commit; v1.0.0 5 years ago

README.md

@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.

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.