fix(date)!: Restore 'format', 'precison', and usage of moment for the date validator
#726
Conversation
- add explicit test for "wrongDateFormat" being raised when options.format is given and not satisfied
…d by ember-validators - the version from ember-validators does not support "now" or "precision" or "format" correctly, and is unlikely to change to support them - indicate that `moment` should be installed in the consuming application, but it does not need to be provided by this package - TODO: allow configuring the date library used, e.g. provide a moment validator, a luxon validator, etc, and allow the consuming applications to indicate which kind should be used.
(This can show up in debounced input scenarios, e.g. where a user is editing both a start and an end date.)
tehhowch
changed the title
moment for the date validatormoment for the date validator
|
It's worth noting that this is a breaking change to only those on Anyone who is still on |
@tehhowch I very much agree with this. We are currently running the qonto@3767e41 in production (as we made efforts to upgrade to ember 4 prior to this addon being adopted). We have also recently replaced Therefore this PR would be a step backwards for us getting back onto the official repo, as we wouldn't want the extra kB's being reintroduced. I also completely understand that this PR would undo some unexpected breaking changes for consuming apps that rely on |
|
@tehhowch I'm on holiday and will have a look after I'm back. I'm still undecided how to move forward with the date validator. I think the addon should not diverge/reimplement too much from I also agree that a more agnostic solution would be great. Next to |
- move new code to "date-moment" validator - TODO: ensure moment is actually optional - TODO: same approach for luxon
Ideally we could just link to ember-validators, but they do not offer upgrading guidance - Some examples need to be fleshed out further
since optionalDependencies will be attempted for install
Resolves #723 .
Changes proposed:
I still think it would be better to support a consumer-defined "use luxon" or "use moment" or "use ___", or perhaps to propose an interface in which the consuming app can massage their preferred date library to support determining the before / onOrBefore / after / onOrAfter relationship states.
git diff d6c95d741fa8388ae2c764037bddcd6c91691f09 tests/unit/validators/date-test.js), while adding some additional tests / ensuring the test assertion messages help convey the test intent.Tasks:
cc: @fsmanuel for visibility