one-com / one-validation

Regexp based validation collection for common internet validation tasks

one-validation

This is a collection of regular expressions for general validation purposes. The basic design concept is to split up the regexes into semantic parts of the pattern to match. As an example a url consists of many parts like scheme, optional userinfo, subdomain, domain, toplevel domain, path, query and fragment. It is a lot easier to write a maintainable and reusable regular expression by mathing each of these parts individually and write a regex that combines the individual later.

The library includes a TLD whitelist that can be updated using make.

This module works as a NodeJS CommonJS module, a require.js AMD module and falls back to exposing itself in the global scope on one.validation if included directly in the page.

Package managers:

• npm: npm install one-validation
• bower: bower install validation

Supported patterns

• domain
• email
• url

Examples

domain and domainIdn

validation.domain.test('foo.co.uk');
return true;

validation.domainIdn.test('hällo-test.de');
return true;

email and emailIdn

validation.email.test('[email protected]');
return true;

validation.domainIdn.test('test@hällo-test.de');
return true;

Building

npm install
make

one-validation's Issues

Create a test suite for regex fragments for inline replacement

577bf85 fixed a bug where foo.com would be matched as foo.co by one.validation.fragments.domain

Create a test suite with inline matches of fragments for potential inline replacement scripts in bigger projects.

slds aren't handled properly by the 'domain' regexp

> require('./validation').domain.test('foo.co.uk')
false
> require('./validation').domain.test('foo.uk')
true

Review the url regexps and make sure that they correspond to the RFC

http://www.ietf.org/rfc/rfc1738.txt

Allow non-punycoded IDNs as host names

require('one-validation').url.test('http://blåbærgrød.dk/'); // false

Underscore should be accepted for sub-domains

Having underscore in sub-domain is a valid use case, but currently not supported by the library.
Please see - https://stackoverflow.com/questions/2180465/can-domain-name-subdomains-have-an-underscore-in-it

Expose regexps without hardcoded ^ at the start and $ at the end