Skip to content
Chris O'Hara edited this page Sep 24, 2018 · 12 revisions

Principles

Some guiding principles I've tried to stick to (by @chriso):

  1. Keep things simple
  2. Make sure the README is kept up to date with validators, options and locales
  3. Prefer small, composable validators, e.g. isAlpha(str) && isLength(str, 0, 10) vs. something like isAlphaOfLength(str, 0, 10)
  4. Avoid adding validators that check for specific character combinations (e.g. alpha + space). There are too many combinations of character sets, so just provide a regular expression they can use instead and close the issue/PR
  5. Avoid adding validators that would bloat the library, e.g. validating phone numbers or even something like semver, particularly if there's an existing library that does it well. People still bundle validator.min.js so try to keep the size down
  6. Try to avoid adding locale-specific validators (e.g. tax codes or national identity number validators) unless they're trivial, they can be generalized, or they're widely requested
  7. Try to grab a reference (RFC, wikipedia page, whatever) for new validators
  8. I mostly ignore the feature request issues. If someone wants it badly enough, they'll submit a PR. Keeping them open for a while is also useful in gauging how many other people want the feature.
  9. If in doubt, open the PR/issue up for discussion and tag me
  10. Keep the CHANGELOG.md up to date after each merge
Clone this wiki locally