Maintainers Guide

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

Release Process

• wait for enough commits to build up. We can release as often as we like, but it takes a while 😅
• Run npm test to make sure tests pass + transpile ES6 + compile the min version. Commit any changes to the git tree here; sometimes a PR was merged but wasn't transpiled/compiled properly because the user didn't run the tests locally
• Bump the version in both package.json and src/index.js. Run npm test again to make sure the version is included in transpiled/compiled versions. We try to follow semver, so if there's at least one breaking change, bump the major version, OR if there's at least one new feature, bump the minor version, OR I bump the patch version.
• Manually update CHANGELOG.md. It's much easier with the squashed commits now but it'd be cool to automate this somehow
• Run npm test again just to check that everything is good.
• Stage the new changes:

git add CHANGELOG.md package.json src/index.js

• If the version is something like 1.2.3, then run:

ver=1.2.3 && git commit -m $ver && git tag $ver && git push && git push --tags

• Once everything looks ready, run npm publish in the local directory.

General Guide on Versioning

1. We use semver: M.m.f -> major.minor.patch/fix
2. A new validator is taken as a new feature, so bumps up m+1
3. An enhancement (eg adding new locale) or fix to an existing validator is taken as a fix, so we bump f+1 (that's if there was no bump in (1) above)
4. When there's a breaking change, we bump M+1, and this overrides the rest for that particular release.

NOTE:

It might be easier/better to lean on GitHub releases more (https://github.com/validatorjs/validator.js/releases), since people may be more familiar with that than looking at a CHANGELOG.md.

Stick with the latest stable node.js when doing the local builds.