||1 year ago|
|.gitignore||1 year ago|
|README.md||1 year ago|
|index.js||1 year ago|
|package.json||1 year ago|
|yarn.lock||1 year ago|
This package contains the
ValidationError type for
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.
new ValidationError(message, [properties])
The constructor for
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.
v1.0.0 (April 20, 2020)