Added a test at #46
Maybe for something as complex as phone number, we should delegate to an external/more robust library?

Caused by #100 , which now just passes value into the native Date.

Prior to #100, a wrongDateFormat error would be raised.

This change is not called out in the changelogs for v4, but certainly should be.

Hi, it would be nice to support moment/computed property in date validator. I have a scenario where some field date must be after another field's date. I guess this example explains it pretty well.

expirationDate: [
  validator('date', {
    // model.createdDate is momentjs object
    after: computed.alias('model.createdDate'),
    precision: 'day',
    message: "Expiration date can't be before creation date.",
  })
]

Do you know how to make it work with current date validator? Otherwise, I can provide PR.

The even check treats 22.22 as not even -- so I think for consistency, the odd check should not treat 21.21 as odd

I have a suggested fix in #90

The following outdated versions are found in your project:

• [email protected], currently used by:
  • [email protected]
    • Depends on ember-cli-babel@^6.9.2
    • Added by [email protected]

The date validation has an option isBlank which is documented like so:

If true, skips validation if the value is empty

This accurately describes the implementation, which skips validation if isEmpty returns true for the value.

Other validators use allowBlank in combination with an isBlank check, and allowNone for an isEmpty check. This is inconsistent; blank should always mean blank, and empty/none should always mean empty.

There may be other validators with this problem, but I haven't checked.

Should this be fixed, and if so, how? One option is to deprecate the current allowBlank option in favor of allowNone, which would behave the same way. At the next major release, you could then add a real allowBlank option if desired.

The recently released 0.1.2 of this package has breaking changes, replacing the packaged in require-module with ember-require-module.

This change breaks offirgolan/ember-cp-validations v2.7.2 which we use, since it's dependency is set to ~0.1.0 meaning it will pull in this version.

I suggest you read up on http://semver.org/, breaking changes should not be part of a patch release.

With Ember 3.21 the getWithDefault function is now deprecated.

It looks like the ds-error validatior stopped working for nested errors. I assume this f829984 might have broken it.

The fix is most likely on this line f829984#diff-ca376f14c1cb0e5696506e00be4f0fa42e7212370c4b5e5bb8eef4970fdcdfceL25

In this case model[path] would work if the path is a simple key like errors. However, if the path is a nested key like foo.errors it won't work. We could fix this by doing model.get(path).

@snewcomer let me know if this is good for you and I can go ahead and create a PR.

I have a PR at #89

Hi!

I'm pretty sure this was not meant to be as it wasn't tested as an accepted value:

• with the inclusion validator, in a number-typed range, NaN is validated as true, whatever happens.

The issue is pretty simple when reading the code: https://github.com/offirgolan/ember-validators/blob/1568f472eb5d9851222b9944521ff1ba529641dd/addon/inclusion.js#L42

When checking their type, NaN and any number will return true as they are all numbers. And NaN is neither superior nor inferior to any number---since it has no value... So it will never return the validationError...

I'll file a PR for that, and I'll add a check to the tests suite.

The link in the README to the documentation site is dead: https://offirgolan.github.io/ember-validators.

Current email validation does not support international characters.

Here's the RFC regarding international characters in email addresses: https://tools.ietf.org/html/rfc6530

Hi! 👋

While working with ember-changeset-validations, which uses this addon quite extensively, I saw there was an "inconsistency" in the behaviour of the date validator's allowBlank option, which checks nullish values and empty strings instead of using Ember's util isEmpty, as per all other validators (cf.).
I also saw that was introduced when removing Moment (cf. commit). Was it meant to be?

We're getting a deprecation warning in our CCI build/test runner:

Using Ember.String is deprecated. Please import methods directly from @ember/string. [deprecation id: ember-string.from-ember-module] This will be removed in ember-source 5.0.0.

The docs for this migration are here:
https://deprecations.emberjs.com/v4.x/#toc_ember-string-from-ember-module

The replacement fix is:
import { classify } from '@ember/string';

app/initializers/export-application-global.js

and

tests/unit/initializers/export-application-global-test.js

and the accompanying code line/syntax change.

Description

Passing a locale like de, it... with a specific format into before / onOrBefore/ after / onOrAfter validator is causing this error:
date value is not finite in DateTimeFormat.format().

This occures, because the parseAsDate is passing the locale to parseDate function, which returns in for locale en the date format 1.1.2015.

new Date('1.1.2015') returns a Invalid Date and this produces this error.

https://github.com/rwwagner90/ember-validators/blob/1282748147a691f3fcffacb0c478a676cc9e309a/addon/date.js#L141-L146

Fix:

There is not necessary to pass locale to parseAsDate, because parseAsDate returns always a new Date object.
We can always pass en-us in parseDate function.

Enviroment

Ember: v3.28.x / v4.x
Ember Validators: v4.1.2

As apps have more options available to them (luxon, date-fns) and moment-core recommends using luxon, we could make this configurable and fallback to browser native. We can also include some of the pitfalls of parsing strings with the Date constructor so ppl know if they might have any issues.

This would allow this validator to have broader use. I'd be happy to do the work.

ref poteto/ember-changeset-validations#208

In the URL regex:

/(?:([A-Za-z]+):)?(\/{0,3})[a-zA-Z0-9][a-zA-Z-0-9]*(\.[\w-]+)+([\w.,@?^=%&:\/~+#-{}]*[\w@?^=%&\/~+#-{}])??/

the (\.[\w-]+)+ is incorrect as it requires at least one dot in the authority, which is not a requirement of valid URLs, and prevents, for example, using http://localhost which is a valid URL. I think maybe changing the \. to a \.? would fix it, but rather than hacking on the existing regex, it probably makes sense to go and find a regex or library that validates URLs and doesn't exhibit this bug.

ref #96 #92 This was a stepping stone to supporting Embroider. Our tests still fail, so we still have a step or two "somewhere" to fix, whether in this addon or in another library.