-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Maintainers Guide
Anthony Nandaa edited this page May 9, 2024
·
12 revisions
Some guiding principles I've tried to stick to (by @chriso):
- Keep things simple
- Make sure the README is kept up to date with validators, options and locales
- Prefer small, composable validators, e.g.
isAlpha(str)
&&isLength(str, 0, 10)
vs. something likeisAlphaOfLength(str, 0, 10)
- 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
- 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 - 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
- Try to grab a reference (RFC, wikipedia page, whatever) for new validators
- 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.
- If in doubt, open the PR/issue up for discussion and tag me
- Keep the
CHANGELOG.md
up to date after each merge
- 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
andsrc/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.
- We use semver:
M.m.f
->major.minor.patch/fix
- A new validator is taken as a new feature, so bumps up
m+1
- 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) - 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.